What does the Secret Key do for you and for us?

What does the Secret Key do for you and for us?

Jeffrey Goldberg by Jeffrey Goldberg on

A unique feature of 1Password’s security is the Secret Key, but its value is often misunderstood by users and security experts alike. Instead of thinking in terms of “is it like a second factor” or “is it like a key file” it’s best to explain it in terms of what it actually does: It protects you if we were to be breached.

The 1Password Secret Key is central to what makes 1Password’s security uniquely strong. It offers our users exceedingly strong protection if our servers were to be breached. However, its uniqueness makes it difficult to understand. Not only is it difficult to understand, it places an additional burden on users. Burdening users with an additional task that is hard to understand is really not our style. The fact that we do so should give some idea of just how important the Secret Key is for security.

A cracking review

Let’s review what happens when some service gets breached. If you already know a bit about password cracking and hashing, just skip this section.

Lots of things happen when a service gets breached, but let’s review what it means for the password someone may use for that service. Suppose Molly (one of my dogs) signs up for the service Barkbook using the password Squirrel!. Molly, as some regular readers may recall, is obsessed with squirrels and really bad at picking passwords. When Molly first signs up, Barkbook will receive the password and store a hash of it. To keep the examples short, I am going to to pretend that Barkbook uses a very outdated password hashing scheme. Barkbook would store something like…

$1$NP8pjY13$Fb/z9cqyMwjysyTodjbec/

…which includes an indicator of the hashing scheme, the salt, and the hash. The hash is the Fb/z9cqyMwjysyTodjbec/ part. Every time someone tries to log in as Molly, Barkbook would use the same hashing scheme with the stored salt to hash the received password. If the hash matches what is stored Barkbook will let the user in as Molly.

Now suppose that Mr. Talk (the neighbor’s cat, who is always up to no good as far as Molly is concerned) has breached Barkbook obtaining the database of password hashes. It’s impossible to compute Squirrel! from 7Fb/z9cqyMwjysyTodjbec/ and the salt. So it would seem that this would not help Mr. Talk with his nefarious schemes. But Mr. Talk can make use of the hash. He can use it to test guesses at Molly’s password. Mr. Talk might very well suspect that Molly’s passwords are based on either the words “rabbit” or “squirrel.” Mr. Talk may also know that Barkbook requires an uppercase letter and a symbol in their passwords. Using this knowledge he can narrow the list of likely passwords to just a few thousand, or tens of thousands. It takes no time at all for Mr. Talk to compute the hashes of all of those likely passwords until he gets a match.

Aren’t hashes irreversible? (Technical aside)

A secure hash function is supposed to be irreversible. That is the hash itself gives you no useful information about the pre-image of the hash. (The pre-image of the hash in these cases is the password that was hashed.) And yet, we are saying that having the hash of a password can be very useful in learning the password. There is no contradiction because the definition of pre-image resistance is explicitly limited by the entropy of the pre-image. That is, it only only hard to guess the pre-image from the hash if the pre-image is hard to guess in the first place.

Because Mr. Talk has the hash, he doesn’t need to test these by trying to log in through the Barkbook login page. Thus any limit that Barkbook has set on failed login attempts won’t get in the way. Mr. Talk can make as many guesses as he wants as fast as his own machine can compute hashes of guesses. This is called an “offline attack” and there is software designed to automate the guessing and testing, and Mr. Talk knows how to use it. It will take Mr. Talk more time to configure the software than it will take it to try tens of millions guesses.

1Password is different

There are lots of problems with the typical password checking scheme. Not least of which is the fact that the password (in our previous example) is transmitted from Molly’s computer to Barkbook each and every time she logs in. We at 1Password never want your account password transmitted to us, so we use a password authenticated key exchange (PAKE) to make sure that no secrets are transmitted when signing in. But that is a whole other story.

The relevant part for today’s discussion is that the PAKE still has the server store something that is like a password hash with respect to cracking. It isn’t actually a hash, but for offline cracking purposes it behaves like one. That hash-like thing is called the SRP verifier.

Make cracking impossible, not just expensive!

There are things that Barkbook can do to make Mr. Talk’s job harder. One thing is to make breaching harder. Because there are many ways that a service can be breached (including insider attacks) there are lots of different things about an organization’s security that need to be looked at and hardened. Another thing that Barkbook can do to make things harder for Mr. Talk is to use a costly password hashing scheme. We use PBKDF2 to harden your account password. But there are limits on what that approach can buy you. Those are good things to do, as they reduce the chances of a breach and they buy users some time in changing passwords in the event of a breach. But they still leave our attacker, Mr. Talk, in a position to do a great deal of damage.

Enter the Secret Key

The 1Password Secret Key changes all of that. It makes the verifiers that we store on our servers completely useless for cracking purposes. Molly’s 128-bit Secret Key gets combined with her rather weak password on her own machine. It’s secret from us and our servers. Recall that no secrets are transmitted from Molly’s 1Password client to our servers when Molly signs into her account. It isn’t merely that we never store her Secret Key – we never even have the opportunity to acquire it.

I have used, and will continue to use, the example of cracking the verifier, as that has a nice analogy to cracking password hashes on a traditional service like Barkbook. But what is at stake here is whether Mr. Talk, given access to what is stored on our servers, would have the capacity to decrypt Molly’s data. Molly’s 1Password Secret Key means that the answer is no. Mr. Talk would not be able to crack that even if he put every computer on Earth to work on the cracking and ran them for zillions of times the age of the universe. I am happy to use words like “never” and “impossible” for that.

The Secret Key means that nobody – Mr. Talk or otherwise – who gets a hold of the data on our servers could ever be able to crack it to decrypt anyone’s data. This not only protects Molly from Mr. Talk, but from anyone, insider or out, who obtains data from our systems.

Responsible planning

We certainly do not plan on being breached, but we must plan for it. As described above, your 1Password Secret Key keeps your secrets safe in the event of a breach even if the attacker has billons of super computers and zillions of ages of the universe to try to crack it. But this does even more. I believe it reduces the chances of a breach in the first place.

If we didn’t have the Secret Key built into 1Password, some user data on our servers would be decryptable if the attacker threw enough resources at cracking verifiers. But because the Secret Key makes such cracking futile, the encrypted data that we hold is far less valuable to an attacker. Why try to steal stuff that you can’t crack or decrypt?

When I first presented the idea of the Secret Key at PasswordsCon in 2015, I described it in terms of a principle of cowardice: We do not want the data we hold to be an attractive target. There is a certain degree of safety that comes from being an unattractive target.

Truck with 'Driver carries less than $50 and is fully naked'

Unlike some of our competitors, our service has never been breached. There are many things one could attribute that to, including luck. But I believe that the 1Password Secret Key plays a role. Sure, attackers try, and we do defend against such attempts. That is the nature of running any service. But because Molly (and every other 1Password user) is protected by their 1Password Secret Key, Mr. Talk won’t try quite as hard to breach our servers as he might otherwise.

Appendix: Is it a second factor?

The Secret Key is not a second factor, and it can lead to confusion to think of it that way. Consumer Reports said in an outstanding review of 1Password:

1Password requires a master password and a code available only through a device you’ve already used to access its service. If you don’t have the device handy, you have to use another long, complex secret code provided to you by 1Password. That can be a chore, but it enhances the security of the box containing all your credentials by requiring another authentication factor.

I can’t blame anyone for not understanding what the Secret Key is (and isn’t). You just read about 1,400 words on an attempted explanation of the unique security properties it gives you and us. And it really is unlike anything most people have ever used. But it’s useful to draw attention to two things they don’t quite get right there.

The first error is what might be implied by “provided to you by 1Password.” That suggests that we create your Secret Key and send that to you. That is not the case. We never have your Secret Key, even for a moment. Your Secret Key is created in your browser or in your 1Password client on your machine when you create your 1Password account. All of that happens entirely on your machine. It may not look like that is what is happening, but that is what is happening.

The second misunderstanding is to call it “another authentication factor.” From the Molly’s point of view it can certainly look like one. It is a second secret that she needs to be able to unlock 1Password on a new device. It sure looks like a second factor at first glance. But as explained above, it is about decrypting the data stored on our servers.

The remainder of this appendix to an already long article is going to get even more abstract. And so you may wish to stop reading here. And if what I say below muddies things instead of clarifying things, forget it.

Keeping things at a distance

Molly may store the key to her toy box right with the box, but Patty (the other, brighter, dog in the house) knows better than to do that. Patty hides the key to her box of toys away from the box. Molly’s system is weaker than Patty’s because an attacker, Mr. Talk, who can get to Molly’s box needs to expend little additional effort to obtain the key to that box. But an attacker who gets to Patty’s toy box has to launch a separate attack to obtain the key to Patty’s box.

In each case, Mr. Talk needs to get both the box and the key. But when going after Molly’s toys, he only needs to do one attack. An attack that will get one will easily get the other. But when he goes after Patty’s toys he needs to perform two attacks. The particular security property that gives two-factor authentication its name is like that. The attacker must launch different attacks to obtain each of the factors.

2FA really isn’t about factors (Technical aside)

Although 2FA is named for its second-factorness and its security is typically described in those terms, it is rarely among the most important security properties of it. In typical usage things that we call 2FA improve security because the long term secret is never transmitted and that what is transmitted is a one-time code. The second-factorness is rarely, so to speak, a major factor in the security of the system. I have presented on this on a number of occasions with a paper (PDF). Nonetheless, second-factorness does a good job at illustrating what I mean by distance between things that need to be acquired by an attacker to succeed in their attack.

In the case of the Secret Key, the distance is between the data stored on our system and your copies of your Secret Key. The attacker who obtains your encrypted data from our servers has zero chance of decrypting it unless they can also obtain your Secret Key from your systems. This distance between what is encrypted with the Secret Key and the Secret Key itself is what makes you, and Molly, safe if our systems are breached. And that same distance dramatically reduces the incentive an attacker would have for breaching our system.

Principal Security Architect

Jeffrey Goldberg - Principal Security Architect Jeffrey Goldberg - Principal Security Architect

Tweet about this post

Continue Reading