Can your password manager provider see your passwords?

Password managers are an essential part of the security toolkit for consumers and businesses alike. They allow you to use random, strong passwords for each of your online accounts, helping to protect against the risk of passwords being exposed in leaks from sites following poor encryption practices. Increasingly they also support more and more features like automatic logins, storing 2FA TOTP codes (a bad idea, but alas), and crucially, syncing your passwords between devices.

Storing your passwords in a vault isn’t a new thing – software like KeePass has been around for decades – but syncing your passwords between devices is. This is actually the crucial element that made the current crop of cloud-based password managers viable. Would you use a password manager that required you to manually copy each password to your other devices every time it is updated?

But if your passwords are syncing between devices using a cloud provider, does that mean your passwords are exposed to your cloud provider?

Your provider can’t read your passwords

No one wants the responsibility of keeping everyone’s passwords safe

The simple answer is no, your cloud provider cannot read your synced passwords. That might seem a little obvious. After all, providing plain text answers to your passwords to a cloud service would be a terrible idea, but it’s a surprisingly difficult problem to solve. It works by encrypting your passwords locally on your device, before sending them to your provider, ensuring that your provider only ever receives your encrypted passwords. These passwords are encrypted with a key derived from (essentially made up from) your master password, ensuring that without plaintext access to your master password, not even your provider can decrypt your data.

The important element here is that the apps and software you use locally are kept secure, which is why it is common practice for the best providers to have their apps regularly audited by reliable security firms, or even to expose the code publicly by open-sourcing the codebase. When you log in to a new device, your encrypted password dump is downloaded to your local device, then decrypted using a key derivation based on your master password.

This is known as a zero knowledge architecture, where the service provider has no knowledge of the data stored on its platform. The provider accepts responsibility for storing and transmitting information, though they don’t have the ability to access it.

Password managers use a neat trick when you sign up

Related

4 best alternative password managers to Bitwarden

You should consider these services if Bitwarden is out of the question.

If you’re following closely, you might’ve noticed a problem. When signing in on a new device, the user must first authenticate with the service provider before being allowed to download the password vault. Once authenticated, the app downloads the password vault before decrypting it using keys derived from the users master password. All good so-far, but if the user authenticates to the provider with their password, surely the service provider needs to have some sight of the password to authenticate the user? Does the service provider not see the password when the user logs in from a new device, allowing them to decrypt the vault?

The trick here happens when the user signs up. Instead of transmitting a plaintext password to the server (plaintext as in, only secured via HTTPS/SSL) like you normally would when logging into an app online, the client hashes the password itself and then sends it to the provider. Providers normally do this on the server side, as it adds complexity when, for example, changing your password. The provider only sees a ‘hashed’ version of the password.

The client only ever transmits a hashed password

Hashing is a one-way function, which takes the original password and derives from it a hash. This hash can be recreated anytime using the original password, but makes it impossible to rebuild the original password from the hash – hence making it one-way. This is essential to basically any online service, as it allows providers to store passwords in a way that they can be validated, but not stored in plaintext.

With password managers, this hashing function is done locally when you sign up. This means the app never transmits your password directly to the provider, allowing them to store only the hash. When logging in from new devices, each device can hash the master password and send it on to the provider’s servers without ever exposing the original master password to the provider.

What about changing your password?

When you change your password, the whole process happens again locally. Your password manager authenticates with the provider, downloads and decrypts your vault, before re-encrypting it with your new password. It then sends the password hash and encrypted vault back to the provider to store.

Forget about resetting your password

The downside of this architecture is that you can forget about being able to reset your password. As your vault is encrypted with your master password, and your service provider has no access to your original master password, they physically can’t decrypt your vault for you. This can be a serious problem if you do forget the password to your password manager.

There is some reprieve though. During your initial setup, you’re given the opportunity to generate recovery codes. These tend to work differently from service to service, but are usually one-time use codes that allow you to recover your account if you’ve lost your password. The cryptography gets a bit complex here. Typically, this either works by a) encrypting your original vault with a multi-key algorithm, allowing multiple new keys to be used on top of the keys derived from your master password, or b) encrypting a second copy of the keys used to decrypt your vault with your recovery codes, allowing the original keys to be retrieved using a recovery code. This can be difficult to implement securely, and some big password managers have added it only recently (1Password only added support in June of this year).

If you’re interested in reading more about how recovery codes in password managers work, 1Password documented its technical solution in a blog post.

Password managers are clever bits of kit

Cryptography is notoriously complex, so we’ve skipped over some of the more gnarly details here, but hopefully this paints at least part of a picture of the encryption-magic going on under the hood of your favorite password managers. Intrinsically, cloud-based password managers might seem like a terrible idea, but with a lot of clever math and some good security auditors, they can be some of the best ways to protect your personal cybersecurity.

Related

I don’t pay for 1Password, LastPass, or Dashlane – these are the free options I recommend instead

Keep your credentials secure without breaking the bank