How to securely share log-in credentials

Improving cybersecurity can feel like a daunting task. Hackers are known for exploiting computer systems using both simple tricks and sophisticated technologies. Defending against them takes time, money, and considerable efforts. And sometimes we unwittingly help attackers. Becoming aware of these mistakes—and making small changes—can lead to great improvements.

I recently watched this positive process unfold at my security-consulting company, Independent Security Evaluators. We hired a new vendor, which as part of its services for us needed access to some of our accounts. It also needed some security education.

A couple red flags: The vendor requested that passwords be sent in an unencrypted document by email, and then asked for administrative access to things it probably shouldn’t have. This is an incredible vendor we remain excited to work with. My point here is not to shame anyone, but rather to highlight a common issue that plagues companies today: Sharing credentials can leave you vulnerable to attack.

READ MORE ON PASSWORD SECURITY

Poor security, not just password reuse, to blame for Disney+ breach
Harris poll backs Google plan to improve password security
Backing WebAuthn, tech giants inch closer to killing passwords
Apple ransom highlights danger of credential stuffing
What to do when your password gets reset
Passwords, hackable yet accessible, are poised to stay popular
How YubiKey could double-lock your online accounts

This common issue often starts with a common refrain: Why is sharing credentials even a problem? Don’t applications encrypt communications, anyways? I’ll explain.

First, sharing credentials eliminates a layer in your Defense in Depth strategy. Defense in Depth is the principle of secure design that the more layers of security a system has, the more resilient it will be against attack, and the lower the impact a breach will have. And vice versa.

Envision a medieval castle. For invaders to kill the king, they would need to dodge arrows raining down as they cross the open field, swim across the moat, scale the walls, fight off the guards waiting at the top, get past multiple locked doors into the inner stronghold of the castle, and fight the king’s personal guard. Every one of those elements makes it harder for the invader to succeed. That’s essentially what Defense in Depth is about.

By sending credentials in plaintext over email, you are conceding their compromise to any attacker who has compromised your email. It would be like the king leaving the drawbridge down and hiding in an unlocked room. It might be fine, but why eliminate defenses? If an attacker successfully pwns your email, it owns all of the content you are sending by email, including passwords shared in email messages. Sharing credentials ultimately makes it easier for your enemy to succeed.

When you send critically sensitive information, such as log-in credentials, via email, you are assuming that your adversary has nothing in common with a bird seed-obsessed squirrel. That would be a bad assumption.

Second, it underestimates your attacker. When you assume that it is safe to send sensitive data by email, you are also assuming that your attacker hasn’t already (and won’t) compromise your email, or that of your recipient. Or won’t successfully implement a man-in-the-middle attack. Or won’t execute a successful phishing campaign. The list of what-ifs could go on and on, but for brevity, the point that you should assume that your attacker is dedicated, relentless, and constantly adapting.

Now envision a bird feeder. It’s designed to attract birds, not squirrels, yet squirrels are relentless in their pursuit of bird feed. If you hang the feeder from a tree, squirrels will climb the tree. If you move it to an unclimbable post, they’ll climb something else and jump. If you move the unclimbable post even farther away, they’ll climb something taller, and jump farther, even at great peril to their own safety. To the squirrel, getting to that bird seed is paramount.

Your adversaries are like squirrels. They will relentlessly pursue what you have. When you send critically sensitive information, such as log-in credentials, via email, you are assuming that your adversary has nothing in common with a bird seed-obsessed squirrel. That would be a bad assumption.

All that said, I get the problem: We work with external parties and sometimes need to share credentials with them. We even need to share credentials internally with our own people. So what is the right way to do this? Here are two simple solutions:

Use a password manager

Most of the major, enterprise-class password managers (such as LastPass, DashLane, and 1Password) have a sharing feature. The idea is simple: you store the passwords in the password manager, and then select recipients with whom you’d like to share the credential.

Through a password manager, you can opt to either allow the recipient to see the password itself, or not be able to see the password at all (but still be able to use it). You should do the latter, which enables them to use the password without knowing what it is. This prevents them from sharing it with anyone else, and it allows you to successfully revoke the credentials when you no longer want that recipient to have access.

Password managers are not without their own security vulnerabilities, an issue ISE investigated in depth in February. However, using one is far better than not using one, even with their flaws.

To summarize:

• Share just the passwords you want, with just the people you want.
• Do not allow recipients to view the password itself.
• Revoke the credential, once the recipient no longer needs it.

Split them up

In the absence of using a password manager, another technique is to send credentials “out of band.” This means splitting the information up, such as sending the username by email and the password by text message. This significantly decreases the likelihood of a successful attack, because the attacker would need to compromise both your email and your text communications, and then know to pair them together.

That sequence is, of course, possible, but it’s far less likely than an attacker compromising just one. Sending in the same band is like writing the combination on the back of your padlock, while sending out of band is like calling your friend to tell her the combo.

There are some downsides to this method too. You cannot revoke the credential later, as you can with a password manager. You will have to change the password, without giving the old recipient the new password. This is a very effective solution, but depending on your use case, it might be a hassle.

This method also gives the recipient the actual password, which doesn’t prevent them from sharing it with anyone else, so you really don’t know exactly who has the credential. There isn’t much of a mitigation to this other flaw than just accepting it as a known risk.

Improved security takes action. I’ve hopefully helped you think differently about how to share credentials with associates, colleagues, family, and friends. Implement these ideas, and you will make important strides in keeping your accounts more secure.