1Password is LayerUp-ed with modern authentication

This year we are partnering with Intel to talk about layers of security, and in this article I’m going talk about how 1Password adds invisible layers of security to what might look like an old-fashioned sign-in page with a username and password. Passwords are not a bad way of proving who you are. But the way that they’re used in practice exposes people to a number of unnecessary risks. It is long past time to move beyond traditional password authentication, and with 1Password accounts, we’re doing so.

Breaking tradition

When we designed the sign-in process for your 1Password account, we wanted something that looks reasonably familiar to people but secures against the risks that a traditional password login does not. Indeed, when you sign in to a 1Password account, although you enter your Master Password, you do not send us any secrets at all. The buzzword explanation is that our end-to-end encryption uses Secure Remote Password (SRP) as a Password-based Authenticated Key Exchange (PAKE) along with Two-Secret Key Derivation (2SKD) to get all of the security properties we want without having to place too much additional burden on the users. If you’re interested in knowing what exactly all that means, read on. Otherwise stop here and enjoy a technical discussion of how migratory swallows can transport coconuts:

Halt! Who goes there? Authenticating (proving who you are) with passwords hasn’t really changed much over the centuries. And I’m going to start my discussion of the security properties it does and doesn’t offer with a very traditional example. King Arthur Queen Penelope approaches a castle gate where a guard (we’ll call him Vincent) is on duty.

Many web services use this traditional method, and many are plagued with the same security problems (which I will get to shortly). As a society we need to be doing much better than this, and we are proud to say that 1Password is doing much better than this!

1Password’s major line of security is its end-to-end encryption: your data is encrypted with keys that never leave your devices. So even if someone does get past the castle gate there is not much they can do with what they find inside. But today we are talking about the security of signing in to the 1Password service.

The problems found in the castle gates method

A method of authentication that has been in place for thousands of years may have a lot going for it. It simply shouldn’t be dropped like coconuts dropped by migrating swallows. But it does bear looking into. And when we do look into it, we see lots of problems.

Reuse: If Penelope uses the same password for multiple castles, then the discovery of one of those passwords in one place can lead to a breach of all of the castles that she uses that password for.

Guessable: The sorts of passwords that Penelope is going to use in these sorts of circumstances are probably guessable with a reasonable amount of effort. This guessing can be made easier if an attacker gets hold of the data that Vincent stores to verify passwords (even if it isn’t the passwords themselves).

Replay: If someone overhears Penelope saying her password to Vincent, then they can use what they overheard to pretend to be Penelope at some later time.

Revealing password to those in the castle: Even if Penelope and Vincent could avoid being overheard, Penelope is giving away a secret to someone who may or may not be the real Vincent. Even if it is the right Vincent, she has to trust him to not do anything he shouldn’t with her password (like pretending to be her at some other castle).

Not mutual: Penelope proves to Vincent that she is who she says she is, but Vincent does not prove to Penelope that she is at the castle that she thinks she is at. Sure, it might be tricky for one castle to pretend to be a different one, but internet services are another matter.

Further communication is still unsafe: If Penelope is brought within the castle walls after authentication, all is good. But if (keeping the analogy closer to an Internet service) she remains outside the castle but carries on conversations with people within the castle, their conversation will still be overheard and perhaps tampered with by someone else outside the castle walls.

Building better castles and gates

Traditional authentication, whether it be castle gates or websites, only really have the client or user proving their identity to the server. But we should be asking for much more security in a modern authentication process. Not only should it have the client prove its identity to the server, but

1. The server should prove its identity to the client (mutual authentication).
2. An eavesdropper on the conversation should not be able to learn any secrets of either the client or the server.
3. An eavesdropper should not be able to replay the conversation to get in at some later time.
4. Client secrets should not be revealed to the server.
5. The process should set up a secure session beyond just the authentication process.
6. User secrets should be unguessable.
7. User secrets should be unique.

I know that a lot of the things on that list overlap, and solving one often involves solving another. But there are some technical reasons for their separation. Also it makes for a more impressive list when they are broken apart this way.

What’s inside the castle

There may be ways for Oscar (Penelope’s opponent) to get into the castle that do not involve providing proofs of identity to Vincent. Perhaps there are other doors. Perhaps it is possible to tunnel in or fly over the walls. Perhaps it is possible to hide inside a large wooden rabbit that is brought into the castle. Perhaps someone already inside and trusted is an enemy spy. Requiring that Vincent check multiple factors will not help defend against any of those.

It is 1Password’s end-to-end encryption that defends against those sorts of attacks. Although end-to-end encryption is probably our most important layer of security, it is not the one that I am talking about today. I bring it up because not only is end-to-end encryption our most important line of defense, but because we need to make sure that nothing in our authentication system could weaken that encryption. We don’t want an attack on the authentication system to give the attacker any information that would be helpful in decrypting Penelope’s data. (Don’t worry if that didn’t make sense at this point; it should by the end.)

With end-to-end encryption the stuff in the castle that is valuable to Penelope is useless to Oscar because only Penelope has the ability to make use of it. Penelope has secrets that never leave her side that can transform her pile of useless stuff kept inside to castle into things that are very valuable. Authentication is about proving who you are and being given access to something. Encryption (and decryption) is about transforming stuff from a useful form into a useless form (and back again).

End-to-end encryption means that even if Oscar gets inside, he will not be able to read the data that he finds. Penelope’s data – even within the castle – can only be decrypted using secrets that only Penelope has and which are never revealed to anyone else.

Once more into the breach

There is one extra thing we need to consider to keep all of this secure. And that is whether an attacker, Oscar, who gets into the castle can use the same information that Vincent has in a way that helps him (Oscar) decrypt Penelope’s data.

When Vincent checks to see whether Penelope has provided the correct password, he needs to check against some data stored some place (perhaps in his head). If computer systems worked like those castles then there might be the same password for everyone and Vincent would know it, too. Fortunately, most web services do much better than that. Each person has their own password and the service should not be storing those passwords unencrypted.

Services do not want to store the passwords that are needed to get into the service. Vincent shouldn’t store that Penelope’s password is xyzzy. Having a piece of paper around with all of that data would be dangerous. So Vincent doesn’t actually have those passwords himself; instead he has password verifiers. (Vincent verifies passwords in this story, and Penelope proves her identity. Oscar is their opponent.)

Making a hash of it (is a good thing)

I have to step back from the castle metaphor at this point, as Vincent needs to do some math that wasn’t around at the time. The verifiers that Vincent stores are typically (though not necessarily) cryptographic hashes of the password. The beauty of a cryptographic hash is that it is quick and easy to compute that the hash of xyzzy is mzgC7LrRFCZ90NGkMeV7C8qVkwo=, but it is pretty much impossible to compute things in the other direction. So in a typical web login system, when Penelope tells Vincent her password, Vincent computes the hash of what she says and then compares that to what he has stored. This way, if Oscar steals the list of these hashes from the castle, the passwords that people use to authenticate remain safe.

But we still have a problem. Even though Oscar can’t compute xyzzy from mzgC7LrRFCZ90NGkMeV7C8qVkwo= he can use that hash to verify guesses. Oscar can guess OnlyUlysses4Me and see what hash it produces. If it doesn’t produce the hash he is checking against, then he tries another guess. If Oscar has the right sort of equipment and a copy of the verifier/hash stolen from the castle, he can make a large number of guesses very quickly. If Oscar knows that Penelope enjoys adventures, he will eventually guess xyzzy, and will see that he gets the right verifier.

One password, two secrets

Now those of you still following along might wonder why Oscar would bother trying to discover Penelope’s password to get into the castle if he already managed to get into the castle to steal Vincent’s list. There are many reasons why figuring out Penelope’s password would be useful to Oscar, but the one that we are concerned about here is that it might be useful for decrypting Penelope’s data. Even though Penelope’s data is encrypted using a secret that only Penelope knows, we want Penelope to only have to know one password to get to her data (be able to retrieve her stuff from the castle) and decrypt it once she has retrieved it. This one password is her Master Password.

Her password, xyzzy, is being used for two purposes. Once is for authentication (getting into the castle) and the other is for her end-to-end encryption to decrypt her data. And this is why – even though 1Password’s security is primarily based on end-to-end encryption – we need our authentication system to not give Oscar anything useful for attacking Penelope’s data. We do not want anything we store to aid Oscar in guessing Penelope’s Master Password.

We want it so that even if Oscar gets into the castle and gets hold of Vincent’s list of verifiers he is no closer to getting at Penelope’s secrets. Although SRP gives us many of the security properties we want, it still leaves Vincent holding a verifier. That verifier – if we didn’t take counter measures – could be used by Oscar for checking password guesses even though it isn’t a traditional password hash.

Two secrets, one password

We want the verifiers that we store to be uncrackable. Our solution is Two-Secret Key Derivation (2SKD ). Penelope has a secret other than her Master Password. It is her Secret Key. When she first sets up her account the software running on her machine will create an unguessable Secret Key. This Secret Key gets blended in with Penelope’s Master Password all on her own devices.

When Penelope proves her identity to our servers, she is not just proving that she knows her Master Password, but she is also proving that she (well, her software) has her Secret Key. In fact, she is proving that she has a combination of these. That combination is unguessable and so cannot be used to get at the secrets needed to decrypt her data.

2SKD means that Vincent only stores uncrackable verifiers. So there is little that Oscar could do if he stole the list of verifiers. SRP means that neither Vincent or anyone listening in during authentication can learn Penelope’s secrets. And with all of Penelope’s authentication secrets nice and secure, they can also be used for the end-to-end encryption of her data.

A very brief word about SRP

SRP and other similar systems involve proving that you know a secret without revealing that secret. As much as I would love to go more into how that happens, this article has become too long as it is. So let me just say that the client and the server present each other with mathematical puzzles that can only be solved with knowledge of a secret, but solutions to those puzzles do not reveal anything about the secret. And because each puzzle is new each time, someone who records a session cannot replay it later.

I’ve tried to give an overview of how the interaction of three things in 1Password’s design – end to end encryption, 2SKD, and SRP – protect your personal information from whole categories of attacks. These design elements are mostly invisible to people using 1Password. You do not need to know about these things to use 1Password well, but we like to let you know it is there. This is all part of how we at strive to make dealing with passwords both easier and more secure. Although not all of the techniques described here are appropriate for all sites and services, we do hope that we that the ideas discussed here can help improve authentication not just for 1Password but for other systems as well.

More detail about all of this and more is in our 1Password Security white paper.

And so a Happy World Password Day to one and all.

Jeffrey Goldberg

Principal Security Architect