1Password is #LayerUp-ed with modern authentication

We should remember on this World Password Day that passwords have been around for thousands of years. They can’t be all bad if we’ve kept them around so long, but some things need to change.

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 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.

11 replies
  1. Brett
    Brett says:

    What a fun and exciting tail. Not sure I’ll be sharing this one with our two year old however. Perhaps the visuals!

    Reply
  2. Nick
    Nick says:

    It might be worth extending this to describe what happens if someone logs into 1Password.com and uses their data online. In that case, the user is clearly typing their Master Password into a web site on a browser which (potentially) they can’t 100% trust, and the MP is presumably sent through to you.

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Nick,

      It might look like the password is being sent to us via the web browser, but that is not the case. When you go to my.1password.com in a web browser, you end up using a web app downloaded from our server that does everything within your browser on your computer. And that includes doing the SRP stuff.

      Although using the web app makes it appear like a “normal” web login and service, everything is actually be done in your browser on your computer, including the decryption of your data. So sometimes what is going on under the hood is much more complicated than how it appears on the surface.

  3. Riley
    Riley says:

    Well written and entertaining. Some quick typos:

    If Oscar knows that Penelope enjoys adventures, he will eventually guess “xyzzy, and will see that he gets the right verifier.
    This sentence is missing a closing quote on the password.
    Our solution is Two-Secret Key Derivation (2KSD).
    This first acronym should be 2SKD, not 2KSD.

    Reply
  4. Nick Rothwell
    Nick Rothwell says:

    @Jeffrey Re: running in the browser. That makes sense – I seem to recall that, at one stage, it was possible to open some index HTML file in a 1Password archive on Dropbox and do much the same thing, with the encryption machinery all running locally. (Perhaps that’s still the case.) I suppose there’s still a risk of a compromised browser, but in that case all bets are probably off.

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      I see you have been around for a while, Rick, that you recall 1PasswordAnywhere. Sadly, that had to die a while back for security and hosting reasons; but yes, the actual encryption code was in the javascript itself and performed entirely on your local machine.

      Browsers are a more hostile environment than when you are running a native app. So all thing being equal, you are more secure using 1Password through a native app than in a web browser, but our web client offers the same encryption and client side operations as the native app despite making thins appear as if they are server side.

  5. Don Nash
    Don Nash says:

    I’ve got one nit-pick:

    “Authentication is about proving who you are and being given access to something.”

    That’s not quite right. Authentication is about proving who you are, full stop. Being given access to something is authorization. They are often combined into a single step, such as authenticating to 1P by definition gives you access to your passwords. But they are conceptually separate things. Or as you put it above, there are some technical reasons for their separation. :-)

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Well spotted, Don. I fudged the definition of “authenticate”, but it was because I wanted to side step an issue of identity. If Alice Liddle creates an account with the name “Foo” and and email address “foobar@example.com” we don’t require that our authentication systems proves that she is Alice Liddle. We don’t care who she is in In Real Life™, we just want to know that she is the same person who signed up as “foobar@example.com”.

      That is, I was trying to say (without going into a long digression) that she proves the identity that is relevant for authorization.

      -j

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *