Confusion about the way password managers work

Question

I've been reading about password managers recently out of personal interest, however since I don't have any experience in the area of information security, I found myself confused about two aspects after watching the following Computerphile video.

Let's say I download and set up one of the commercially available password managers on my device A. I understand that what the server (i.e. the 'vault') stores is only encrypted information that is useless if intercepted. To decypher this information, one needs some kind of a 'vault key' generated from my master password by hashing it. I can verify my identity with the server by using the authentification key, then download my vault and decypher it to recover the actual passwords on device A.

1. Now, if I try to do the same on device B, in order to authenticate myself again, presumably I need to replicate the same hashing procedure to tell the server it's me again who's trying to access the data. If that's true, then the information about how to hash my master password correctly has to be somehow transferred from A to B? Does that not leave the possibility that someone can intercept that information when it's being synchronised across devices and therefore pose a security threat? Or does it simply not matter as long as the attacker doesn't know my master password, since then they won't be able to reproduce my vault key or authentification key anyway, even knowing the right hashing procedure?

2. Can the authentification key be intercepted when it's trying to access the encrypted data on the server? Then, the attacker would be able to access and download all this data. Again, is that not a concern because, as the video mentions, there is no way to replicate the vault key from the authentification key, so the data cannot be decrypted? Why is that impossible?

Please point out any mistakes in my reasoning. I would be grateful if you could recommend some resources about how password managers deal with security issues like that in greater detail - the information readily available on their websites is quite basic and I don't really know where to look for something in-depth.

Answer 1

No communication is needed about "how to hash my master password correctly". That information is the same for every device and is defined by the password manager software which you run on your computer.

As for intercepting the hash, the most secure password managers would either use a "zero knowledge" system like Secure Remote Password (SRP) to prevent your password from ever leaving your computer in usable form (for example, 1Password uses this); or alternatively they might use a separate "account password" to log into the provider's server and retrieve the vault, with a different "master password" used to actually decrypt the vault.

Less secure password managers might actually send your master password, or some hash of it, to the server directly. This could in theory be intercepted as you fear, however any password manager with even a modicum of security will at least do the login over HTTPS or a similar encryption channel, which will prevent any such interception unless you or their servers are already compromised in some way, or unless they have made a mistake in the implementation which adds a vulnerability that can be exploited.

Answer 2

[Disclosure: I work for 1Password]

These are really good questions. I am mostly adding to Ben's excellent answer, but I feel that I have enough additional to say to make this worth a separate answer.

You also mentioned that you hadn't seen this explained anywhere. Much of what I say is discussed in the first few chapters of the 1Password security design document (PDF).

You raised, directly or indirectly, a number of separate questions

Key derivation versus comparing hashes

Implicit in your question is a very understandable confusion between "hash and compare" authentication with the way that key derivation is used in many password managers. For traditional authentication systems, a hash of a password is stored, and a system will hash the user provided password and see if those match. If they match the system says "ok, you are who you say you are."

But that isn't the only way authentication can work (I will get to that later), and it certainly isn't the way that decryption works. For decryption you take the password (and other stuff) and derive a key that is used to decrypt (keys that can decrypt) your data.

Hashing is an part of key derivation, but the goal is to derive a secret that is not stored anywhere. It is not to derive a hash that gets compared to a stored hash.

With that out of the way, we can go on to your other questions.

How do different clients know how to derive the keys?

As you correctly noted, you need to be able to derive the same authentication and encryption keys on all of your devices for you to be able to use your data on all of them. This can be very safely managed. You stated your question in terms of hashing, but the more correct notion is key derivation.

When you first create your account, your client will pick some key derivation parameters and generate a non-secret salt. It will send that information to the server. There is nothing secret in that. (It will also send something else that I will get to later.)

I will talk about the choice of key derivation function (KDF) and its parameters as "KDF parameters" in what follows.

When you try to authenticate from a new device, you give the server your username. (In 1Password's case you need to give it some other account information as well, as you can have different accounts with the same username, but let's just pretend that you only need to give it your username.) The server will look up the KDF parameters that you'd sent it when the account was first created and it will send this to back to you on your new device

With the same salt and KDF parameters you can derive the same keys as long as you provide it with same master password (and other user secrets). The key derivation function is designed to be deterministic.

Not sending secrets during auth

In a traditional authentication process you send a secret, your password, to the server, the server hashes it and compares that hash with what it has stored. In the case of a password manager that involves sending a very high value secret to the server, which is not something we want. Even if the server were to forget the password sent to immediately after the hashing, there are numerous things to worry about with such a scheme. A bug or malicious code on the server would be able to capture and store those passwords. A very bad thing.

When we designed 1Password's authentication scheme we did not ever want to see your master password. There were roughly two approaches. One would be to have users have a different authentication password than an encryption password. There are ways of doing that under the hood to still live up to our name of one password. For reasons I won't get into, we rejected that approach as the various schemes still gave us too much information during authentication.

The other approach, which we took, was to use an authentication protocol that doesn't involve any secrets to be transmitted during authentication. We needed to use a PAKE (Password-based Authenticated Key Exchange). And the PAKE we chose was SRP (Secure Remote Password). Here, in somewhat abstract terms, is how that works.

When you first create your account you use the KDF and your master password (and other user secrets) to derive a key called the SRP-x. That SRP-x is your secret and should never be transmitted. You can always rederive it from your master password and the KDF parameters. From that x, you can compute something called the SRP verifier. It is possible to compute the verifier from the x, but the reverse is not possible. You transmit the SRP verifier to the server during enrollment, and that is the only time anything kind of secret gets transmitted.

During authentications, the server has the verifier stored and you can re-derive the SRP-x from your master password. Here is the cool part. There is a mathematical relationship between the x and the verifier that means that it is possible for each party to prove that they have x and v to each other without having to transmit any secrets. They mutually construct a math problem (which is unique for each authentication) that allows the server and the client to prove to the other that they hold their respective secrets (the verifier or the SRP-x) without revealing any secrets to each other or to an eavesdropper.

Separating encryption keys from authentication keys

The key derivation process allows the to derive a different secret used for encrypting/decrypting data and for authentication. So the SRP-x cannot be used to decrypt data. It can only be used for authentication as described above.