Order now

On Sharing Passwords

Storing passwords is one problem, but far too often, those passwords also need to be communicated to a third party (say, when provisioning an account for them) – a dangerous affair: Bit-for-bit, no data leak is more damaging than a compromised password, so sending them into the wild, bereft of the multi-layered safeguards developed at great expense to protect them is never preferable. Reality is rarely so accommodating however, and since “sneakernet” isn’t always practical (interns ask questions when you handcuff them to briefcases, for some reason,) a discussion of secure remote options is in order.

Plan A: Don’t share them in the first place

Actual “man-in-the-middle” interception of email is indeed concerning, but the greater risk lies in putting passwords into user’s email at all – it effectively moves your carefully guarded password into another database exposed to multiple attack vectors.

Since we can’t rig emails to explode after being read, MI5 style, the next-best solution (if your software supports it) is simply sending the recipient a single-use password reset link: Aside from alerting the recipient immediately if the message was intercepted (a “link already used” error message,) if the stored e-mail is later leaked (with the rest of the recipients email database, as is common,) the expired link is harmless. Without a default password, users are also forced to pick one themselves, and are not given a chance to keep any (possibly insecure) default. They still need to make sure their new password is safe, of course.

Even here, care must be taken: Ensure that your password reset forms don’t ask for the user’s old password – as the recent Podesta e-mail leak demonstrated, that only trains your users to fall for phishing/spear phishing attacks.

Plan B: Encryption

On rare occasion you’ve no choice but to share a password directly, purely through e-mail. There is no silver bullet solution here: The data you send are inherently at risk.

PGP, usually in the form of GnuPG is still the least bad of the options: Once you have a verified public key of your recipient, you can send them the password inside an encrypted e-mail (using one of the GPG plugins available for various e-mail clients).

It mostly solves the problem of later leaks of the recipient’s e-mails (as the recipient’s private key will be needed to decrypt the e-mail); however, preventing man-in-the-middle attacks is needlessly involved, as GnuPG has cumbersome UX for verifying keys.

(TeamPAVE, meanwhile, sidesteps both problems completely: Key trust is configured centrally in your backend,, and passwords can be shared easily via PAVELinks.)

Published on Dec 1, 2016 by James Simakas

James Simakas