Share Passwords Securely with One-Time Secret
Have you ever needed to send someone a password? Perhaps a new volunteer is helping to update your club’s Web site, or you need to give someone access to your organization’s Twitter account. Sending an email message with all the necessary login information is the worst possible way to do this, since it puts the account’s username and password together in a convenient package that could potentially be sniffed in transit, seen on an unlocked Mac, or accidentally forwarded to the wrong contact. Even using Messages, which has a secure transport mechanism, isn’t ideal, since someone other than the recipient could later scan through your conversation history and see the account credentials.
A better approach would be to send the username (and any login URLs) in email, and then send the password separately in Messages, without saying that’s what you’re doing. That way, someone with access to the recipient’s computer would have more trouble connecting the two bits of data. But that method isn’t foolproof and all the necessary login info may still live on in various accessible places.
A better solution is offered by a free Web site I ran across recently, called One-Time Secret. Conceptually, One-Time Secret is simple. You enter some secret content like a password, click a button, and the site returns a link that can be used just once to retrieve your secret content. If the link isn’t used within 7 days, it expires. Links look like this:
To use One-Time Secret, visit its Web site, paste the relevant password from your password manager into the “Secret content goes here” field, and press the Create A Secret Link button.
Copy the link that’s generated, and send it to your recipient.
How you choose to do that depends on the importance of the account. For most situations, where hackers aren’t actively targeting you and the account in question doesn’t protect confidential data, it’s probably fine to send the username and the link to the password in separate email messages so they can’t be connected easily. For more security, send the username via email and the password link via Messages (or vice versa). Whatever method you choose, follow up with the recipient to make sure they were able to retrieve
the password and store it in their password manager.
That follow-up is key. Since a One-Time Secret password link can be used only once, if the recipient isn’t able to access it, that’s solid evidence that someone else did. If this happens, change that password immediately!
These ways of transferring a password suffer from one major concern — what if someone is intercepting all traffic between you and your recipient? Or worse, has compromised the recipient’s computer such that the attacker can read all email and text messaging traffic? Unlikely, I know, but you can step up the security at One-Time Secret to address this possibility. In essence, you’ll protect your password with another password.
To do this, when you’re creating your password link, enter a word or phrase into the Passphrase field (make it easy to type, since you’re not going to communicate it as text). Then call your recipient — via phone, Skype, FaceTime Audio, Google Hangouts, Slack, or whatever — and convey the passphrase audibly. When they use the One-Time Secret link you send, they’ll be prompted for that passphrase, which only they could know, since it was transferred in an entirely different fashion. For the ultimate in security, you could communicate the passphrase indirectly with information only the two of you would be likely to understand (“It’s the nickname we use for the lead developer.”). Yeah, cloak and dagger stuff, I know.
The other advantage of using a passphrase is that One-Time Secret uses it to encrypt the secret content. Without using a passphrase, One-Time Secret has to store your private content until it’s retrieved, creating a 7-day window during which the site could conceivably be hacked. Of course, as long as you’re sending only passwords, without usernames or other login information, there should be a vanishingly small chance of the password being connected with the right
account. But if you worry about that, just use a passphrase to encrypt your content and communicate the passphrase in person.
When used without an account, your secrets expire after 7 days and can contain a maximum of 25 KB of text. If you sign up for a free account, the expiration time increases to 14 days, and you can communicate up to 50 KB of text. These maximum sizes mean you could use One-Time Secret for messages other than passwords, but remember that the recipient can always create a copy of the text. The other advantage of signing up for an account is that One-Time Secret can send its links via email to recipients for you, making it seem as though the email comes from you. This isn’t a big win over copying and pasting the link manually, but it could be useful in some situations.
If you send someone a secret and regret it immediately, the confirmation screen provides a Burn It button that lets you delete your secret such that the recipient following the link won’t have any idea what the secret was.
For sysadmins who can reset user passwords but don’t want to know the new passwords, One-Time Secret offers an “Or Generate A Random Password” button. It’s intended to simplify the process of creating and sharing a password by making it a single step.
Sysadmins and developers will also appreciate the fact that One-Time Secret’s code is open source, so you could install it locally, and it even has an API and client libraries. That may be meaningless to those who aren’t programmers, but the practical upshot is that those who worry about using an Internet service can host it on a secure server, and if there were nasty backdoors or other problems with One-Time Secret, someone could have discovered them by now.
(After this article first appeared on our Web site, I was informed of a competing Web app called d-note, which claims to have better security. It’s also open source, and comes with instructions for installing on your own server. Although d-note can’t generate random passwords for sysadmins, it can create a QR code that you send to the recipient, who scans it to reveal the secret password instead of following a link.)
One final aside. The problem I solve with One-Time Secret is infrequent, one-off password sharing with people whose technical setup I seldom know. If you want to share passwords more regularly, better password managers like 1Password and LastPass simplify sharing as long as everyone uses the same app. In an ideal world, 1Password and LastPass would integrate the code from One-Time Secret or d-note into future versions to provide ad-hoc password sharing too.
I can’t say I use One-Time Secret regularly, but I’ve become quite fond of it, particularly when sharing passwords with non-technical friends, since it hammers home the need for using strong passwords and not communicating or storing them insecurely. Give it a try the next time you need to share a password!
If I'm going to call the recipient to audibly given them the passphrase to decrypt the password text, why don't I just give them the original password and skip all the hassle with the website.?
Because it's really hard to say every character in a 20-character random password. And if they get it wrong, you have to do it all over again.
I usually use iMessage, which, I'm told, is encrypted end to end and also on Apple's servers, what are my risks with that method (assuming I'm not using my Mac which may have a keyboard logger)?
Would it help if both of us deleted the message after confirmation of receipt to remove it from the servers?
Deleting the message on both sides would help, since it eliminates the possibility of someone shoulder-surfing or being able to look through the transcript later.
I wonder if we all becoming too paranoid about the remote possibility that an unauthorized person could access our account information. Being careful about our passwords to our financial accounts is one thing, but who we ever share those with? I cannot envisage a scenario in which someone would want to get into my Twitter account, and even so, what harm could they do.
The problem is that you never know what information could be revealed or what mischief could occur if someone were able to get into one of your accounts. In the worst case situation, it would lead to a domino effect where they could get into multiple accounts, including online banking.
More likely is that a machine could be taken over for sending spam or participating in a botnet. For instance, my local running club has a Web site that a number of people need to access, so we use One-Time Secret to share that password. Given that it's a volunteer organization, having to recover from being hacked could take a long time.
For anyone who would like to read this article in Portuguese, here's a translation:
And for those who would like to read in Russian, here's another translation:
And now it's available in Estonian too!