You have secrets; we don’t. Why our data format is public

1Password 4 for iOS iconThe security of your 1Password data depends on only one secret—your Master Password. It also depends on plenty of things that aren’t secret. For example, 1Password uses the AES encryption algorithm, every detail of which is defined by public standards; your security depends on the security of AES, but there is nothing secret about it.

Another non-secret is the design of our data format, including the Agile Keychain format and the Cloud Keychain Format. Indeed, we have a history of being very open about our data format, and this is good for your security.

Third party apps and 1Password data

Let me jump to the what has prompted this article before returning to the virtues of publicly detailing our data format. Recently there’s been progress on third party tools and applications that can read 1Password data, and there are some important factors to consider about these tools:

  • Third party tools for reading 1Password data do not reflect a “break” in 1Password. They, like 1Password, require your Master Password in order to read your data.
  • We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password. We aren’t casting aspersions on the integrity or competence of any developers, but we simply can’t advise otherwise.
  • Third party tools are “third party”. Although we may sometimes help them understand the details of our data format, they are entirely independent of AgileBits. The fact that we may maintain a good relationship with them is not an endorsement of what they produce.
  • Third party tools exemplify the fact that there is no data lock in with 1Password.

The existence of third party tools for reading 1Password data has had people ask about the security implications of us being so open about our data format. Our openness is a good thing, and here’s why.

No lock-in

Vendor lock-in, roughly speaking, is when you depend on a particular vendor to be able to use what is already yours. An example that many of us face is with ink for inkjet printers.Most expensive liquid infographic

The manufacturers of various inkjet printers make it very hard for you to purchase ink from any other vendors. Thus, to continue using their printer, you need a supply of their ink. Not only does that get expensive, but if you spent a lot of money on the printer, you need to worry about what might happen if the vendor goes out of business and no longer provides ink. You may not be able to use your printer at all.

I have more than 1500 items in my 1Password data, and it would be absolutely catastrophic if I were to lose access to these. This is, of course, why good backups are essential and why I need a Master Password that I’m not going to forget. “Data availability” is the jargon used for this aspect of data security, and it is one that people often overlook. Years ago, I wrote about the importance of backups in “Keeping your data at your fingertips (Part I)“, then I wrote about being sure you have access to those backups. Now it’s time to talk about part II of that first article: avoiding data lock-in.

Could you lose access to your own password data if we disappeared from the face of the Earth or turned evil? We have no plans to do either, but you should know that even if the worst were to happen to AgileBits, you would still have access to your data. One of the reasons for this is that, once you have purchased a copy of 1Password, you can continue using it forever as long as you have an operating system that supports it. Our (rare) paid upgrades are optional.

The second way we avoid locking you into 1Password is through the ability to export data to a more neutral format. Not all versions are yet where we want them to be with respect to export, and we’re working on that. But there is usually some path, if not always a simple click away, to export your 1Password data.

Enabling third parties prevents lock-in

It’s this third way that we avoid lock-in that is relevant to today’s topic. Our data format design is specified well enough so that people with no connection to AgileBits can write software to be able to handle it. Of course your data remains completely unusable without your Master Password; third party software still needs you to enter your 1Password Master Password.

There are, indeed, at least two projects independent of us, which are developing software that can read 1Password data (once you’ve given them your Master Password.). James Brown (@RogueLazer) has developed some Python libraries which can – given the Master Password – read both the Agile Keychain Format (1Password 2 and 3 for Mac, 1Password for Windows) and the Cloud Keychain Format (1Password 4). Indeed, RogueLazer’s efforts and queries have led to substantial improvements in our documentation. Another project is the very recent release of the tooPasswordapp for iOS. Its developers tell me that they worked straight from our documentation. I should also add that, in its own way, the John the Ripper module for the Agile Keychain data could be called another third party tool.

Without passing any judgement on any third party developers, we have to advise people to never enter their 1Password Master Passwords into anything other than 1Password. I have no reason to doubt the integrity or competence of these third party developers, and RogueLazer’s project is even open-source. But it would be irresponsible for us to do anything other than advise you never to give your 1Password Master Password to anyone or any other application.

So while we can’t endorse those systems, and indeed we have to advise you against using them; their existence is still a Good Thing. They are proof that our openness about our data formats means that you do not have to fear data lock-in.

Kerckhoffs’ Principle: No secrets beyond the key

Auguste KerckhoffsKerckhoffs’ Principle states that you should assume that your adversary knows as much about the system you use as you do. This is why – despite what I may have said on April Fools Day last year – security experts are skeptical of security systems that hide the details of how they operate. They are particularly skeptical of systems that derive their security from keeping the details of how they work secret. I could go on at great length about why openness about the system improves security. Indeed, my first draft of this article did go on at great length. I’ll try to be more concise this time through.

Too Many Secrets

If the security of a system depends on the secrecy of the system (in addition to the secrecy of the key) then that secret is actually a vulnerability.

xkcd code talkers comic

Suppose my two dogs, Patty and Molly, have developed their own security systems. Mr Talk, the neighbor’s cat, wants to break into their systems. Patty has developed hers so that all of the secrecy is in her password. Everything else about the system can be made public. The security of Molly’s system, on the other hand, depends not just on her password, but also on keeping aspects of her system design secret.

Mr Talk will study both systems very carefully. He’s very patient and will pick them apart. As he learns more about Patty’s system, it doesn’t get any weaker. After all, Patty made the details of the system public in the first place. But as Mr Talk learns more about Molly’s system, the weaker it becomes. From Mr Talk’s point of view (that of the attacker), Molly’s system has a vulnerability that is waiting to be discovered through analysis. Indeed, Molly’s system has that vulnerability by its very design.

Public scrutiny

It’s easy to use the Advanced Encryption Standard (AES) algorithm from some standard library in some software and call it secure. AES is certainly strong enough. But unless it is used in the right ways at the right times as part of the right constructions, it would probably be a mistake to call such software secure.

We do believe that we use AES, PBKDF2, HMAC and other technologies in the right ways at the right times in the right constructions. A great deal of care and research went into those sorts of decisions. But the only way for the world to share our confidence is if we document our decisions. Sure, most people aren’t in a position to directly evaluate said decisions, but everyone can take comfort in the fact that there are enough people who can, and do, look at those details.

We’ve been here before, and we’ll be here again

This isn’t the first time Kerckhoffs’ Principle has come up. I specifically discussed it when talking about creating good, strong Master Passwords, when I said that we should use a system for coming up with Master Passwords that doesn’t lose its strength if the attacker knows the system that we used. Kerckhoffs’ Principle also came up (though not by name) in discussion about how 1Password stands up to password cracking tools.

All of this is to say that Kerckhoffs’ Principle runs strong and deep through 20th and 21st century thinking about cryptography. Even if I don’t mention it by name, you should keep an eye out for it.

Authenticated Encryption and how not to get caught chasing a coyote

Enigma machineI introduced HMAC (Hash-based Message Authentication Code) through the back door when talking about the Time-based One Time Password (TOTP) of Dropbox’s two-step verification. But TOTP is actually a peculiar way to use HMAC. Let’s explore what what Message Authentication Codes (MACs) are normally used for and why they play such an important role in the future of 1Password. If you guessed that MACs are for authenticating messages, you’re on the right track.

In a sense (but this is a lie), you can think of MACs as kind of like encrypting things that aren’t secret.  The recipient doesn’t decrypt the data, instead the recipient verifies that it really was the data sent by the sender and that the data hasn’t been tampered with. MACs work with the sender and the recipient both sharing a secret key. (This is the key difference between MACs and digital signatures. With MACs, the sender and the recipient share the same secret key.)

Only someone with knowledge of the secret MAC key could have created the MAC for some data, and (unlike the case of digital signatures) only someone with knowledge of the secret MAC key can verify that the MAC is valid for the data.

 Why use a MAC?

Suppose my dog Patty (the clever one) leaves a warning for Molly (a simple dog) that says, “There’s a coyote in the back yard”. The message isn’t secret. Neither Patty nor Molly care who reads it. But now suppose that the neighbor’s cat, Mr Talk, in his attempt to get rid of Molly, changes the message to “There’s a squirrel in the back yard”. HMAC diagram This would not be good news for Molly, who would blindly run behind the house, chase a squirrel up a tree and then bark at it for the next thirty minutes. Coyotes, however, do not climb trees; and so Molly would have an entirely different experience if she tried the same action against a coyote.

To avoid tampering with the message, and to prevent Mr Talk from sending a counterfeit message in Patty’s name, Patty and Molly can share a secret key which is used to create a MAC of the message. Suppose that Patty and Molly, ignoring earlier advice on creating passwords, have secretly agreed on the key (well, a password from which a key is derived)—”Kitty Smells”—for their MACs. When Patty constructs the message, she will calculate the MAC (and if she is using HMAC with SHA1 as the hashing algorithm) with ‘Kitty Smells’ as the password, the HMAC should come out as:

a3b3a8b79c135ff5b9a0aa6f5c304b411f07f90c.

Patty will leave the message, “There’s a coyote behind the house”. along with the MAC.  When Molly sees a message, she should verify the MAC before even looking at the contents of the message."There's a squirrel in the back yard" Forged document with HMAC If Mr Talk has changed the message to say “squirrel” instead of “coyote,” the MACs won’t match up. Mr Talk cannot create a valid MAC because he doesn’t know the shared secret password used to create the secret key that Molly and Patty have.

Sadly, Mr Talk’s trick will still work.Molly transfixed by "squirrel" That is because as soon as Molly encounters the word “squirrel” she will react. All thoughts of verifying the MAC will be pushed out of her brain, which will now be entirely occupied by the single thought, “squirrel”. Indeed, if I were reading this aloud, Molly would have run out the back in blind excitement.  This is why it is very important to not even look at the contents of a message before verifying its authenticity.

MACs on encrypted data

In this example, the original message isn’t secret and so didn’t need to be encrypted. But with authenticated encryption, we first encrypt the message with an encryption key and then compute a MAC of the encrypted text using an authentication key. Just as it was important for Molly to not do anything with the message until she verified the MAC, it is vital that we don’t try to decrypt an encrypted message before verifying the MAC. This system is called “Encrypt-then-MAC”, but the emphasis should be put on the other end of the process. I like calling it “Verify-then-decrypt”.

A scheme like Encrypt-then-MAC that both encrypts a message and provides authentication (proof of who it came from) is called “authenticated encryption”. Encrypt-then-MAC isn’t the only secure authenticated encryption scheme out there, but it is the one that we use in the 1Password 4 Cloud Keychain format.

It’s already encrypted with a shared secret. Why verify?

You might think that there is no reason to authenticate encrypted data. After all, the data was encrypted with a secret key, so if you can decrypt the message with that secret key, then you know it only could have been encrypted by someone with knowledge of the secret key. Many people have thought that, but they were wrong.

Suppose that Molly sends an encrypted message to Patty, but doesn’t use authenticated encryption. Now when Patty gets a message from Molly she decrypts it. If the decrypted message is garbled in a specific way, Patty tells Molly that it didn’t decrypt properly and that Molly should send it again. If it isn’t garbled in a particular way, Patty will just let Molly know she got the message.

Padding oracleMr Talk can listen to this exchange between Patty and Molly. Without the secret encryption key, Mr Talk won’t be able to figure out what is in the message that Molly sent to Patty. But now suppose that Mr Talk is able to send encrypted messages (seemingly from Molly) to Patty. Mr Talk can send Patty modified forms of the message that Molly sent and find out whether Patty got a garbled message when she decrypted it. Mr Talk makes small changes to the original encrypted message to create a bunch of new slightly different encrypted messages. By finding out which ones are garbled and which ones aren’t, Mr Talk can actually decrypt the original message. This is a type of “Chosen Ciphertext Attack (CCA)”. It is called this because the attacker is able to choose ciphertext for the recipient to attempt to decrypt.

Now, the particular attack that Mr Talk used depends on the precise details of how Patty determines whether a message was garbled. That means changing those details can defend against this particular attack. Those who are familiar with all of this will know that I’m talking about the “padding oracle attack”, and will know that it can be defended against by using different padding or using a different encryption mode. But such a defense only addresses this particular attack. Is there a way to defend against all CCAs, even those that haven’t been invented yet?

The good news is that it is possible to defend against all Chosen Ciphertext Attacks. The way to do that is to properly use authenticated encryption. Padding or other “oracles” are not a particular threat to 1Password, as there is no back-and-forth exchange in normal operation. These sorts of attacks are practical when there is an automated oracle on the network or in a specific device that will attempt to decrypt ciphertext on demand. In 1Password, there is no opportunity for an attacker to set up the kind of dialogue needed for this kind of attack.  But we also know that theoretical weaknesses have a habit of turning into exploitable weakness over time. So we look ahead, and build authenticated encryption into 1Password now.

What happened to Molly?

I am pleased to say that no harm came to Molly or the coyote.  She was on her leash, and you can see in this staged and contrived photo that I was – just barely – able to restrain her from running to her doom after a coyote. However, our attempts to teach her that she must verify messages before she does any other processing of said messages have not gone well.

Restraining Molly

Hashing fast and slow: GPUs and 1Password

The net is atwitter with discussion of Jeremi Gosney’s specially crafted machine with 25 GPUs that can test hundreds of billions of passwords per second using hashcat, a password cracking system. Password crackers, like hashcat, look at the cryptographic hashes of user passwords and repeatedly make guesses to try to find a password that works. 1Password has been designed to resist automated password cracking attempts exactly because we anticipated developments like this.

Don’t get freaked out by the numbers

Windows XPFirst and foremost the reports of 348 billion passwords per second is specifically about passwords stored in the LM format used on Windows XP, exploiting the notorious design flaws and limitations LM hashes. (If you are still running Windows XP; and particularly if you are running NT, 2000 or 2003 domain controllers, please, please upgrade.) The hundreds of billions of  passwords per second reached against those hashes does not mean that passwords stored in other formats can be cracked that quickly.

By the way, this isn’t the only important news about password security to come out this year’s excellent Passwords12 conference. I couldn’t quite make it there this year, but I will talk about other developments from it in coming weeks. Today, all eyes are on GPUs guessing billions of passwords per second.

Slow and Fast Hashing

Typically when a password is “stored” on a system that you log into it is not the password itself, but instead it is a cryptographic hash of the password. I’ve written about some of the ways that password  can be hashed before. HashcatThese can roughly be divided into two categories: slow hashes and fast hashes. Slow hashes are specifically designed to slow down the kinds of attacks we are discussing.

Your 1Password Master Password is processed using the slow hashing system known as PBKDF2. 1Password’s use of PBKDF2 and your use of a good Master Password keep your data resistant from password crackers such as John the Ripper and hashcat if you chose a good Master Password.

Defending against future threats

There are several lessons from this. Gosney’s work does reflect real innovation and a breakthrough, but it isn’t an unexpected breakthrough. People who keep an eye on these things – and we do keep an eye on these things – expected something like this within the next couple of years.

We need to design systems that work against plausible future threats, not just against current threats. This is what we have always tried to do with 1Password.

Lessons and actions

  1. Your 1Password Master Password and your 1Password data remain safe, we designed the Agile Keychain format from the beginning to resist crackers like this. But it is also important for people to select strong, memorable, Master Passwords.
  2. It is more important than ever to have unique passwords for each site and service. As password cracking gets easier, the risks of using the same password on multiple sites increases. This is because if password hashes are stolen from one site, attackers have a better chance of discovering the password from the hash. Once they have that, they can try the same password on other sites.
  3. When using 1Password’s Strong Password Generator, try to create passwords that are at least 20 characters long.

Back to the Future

Gosney slow hash chartI’ve talked (well even boasted, I suppose) about how our earlier design decisions are protecting 1Password users today. But we have to look at what design decisions we make today will do for 1Password users half a decade from now.

Gosney’s machine can also be used against slow hashes, including PBKDF2 passwords. You can read more (and see cool pictures) of the design of Grosney’s hashcatting machine in the conference presentation slides (PDF).

Furthermore PBKDF2 was not designed to specifically impair parallel processing. But because GPUs have unusual and restricted ways of addressing memory, it is possible to design systems that make parallel processing using GPUs slower. This leaves a number of questions that we continue to look at.

  1. Do we need to change anything at all in anticipation of even more powerful machines tuned toward PBKDF2? (We don’t yet Password Based Key Derivation Function diagramhave estimates on how many passwords per second this system could try against a 1Password data file.)
  2. If we do need to change things, when do we need those changes need to be in place?
  3. Should we look at more parallel and GPU resistant alternatives to PBKDF2, such as scrypt?
  4. Should we look at tinkering with options within PBKDF2 to make it more resistant to GPUs working in parallel?

These are not new questions. We are always asking ourselves these and other questions in order to keep your 1Password data secure and protected, both now and in the future.

[Updated 2012-12-06 15:50 UTC. Updated to correctly explain that Gosney’s system is not limited to LM hashes. Thanks to Jeremi Grosney, Solar Designer, and others who pointed out my error. I have also taken the opportunity to add more clarifications and links to background throughout.]

Credit card numbers, checksums, and hashes. The story of a robocall scam

Sample Bank of America debit cardAs  Lívia and I were out walking Molly and Patty on Monday evening, I received a telephone call from an unknown number.

I decided to answer the phone anyway, and I was greeted by a recorded voice telling me that my Bank of America debit card beginning with 4217 has been limited and whether I would like to revalidate it.

I don’t have a Bank of America debit card (though I did many years ago), and I know US rules bar most calls that begin with recorded messages, otherwise known as “robocalls.”  I also know that the first few digits of credit card and debit card numbers indicate the card issuer and so are not secret if you know that it is a card issued by a particular bank. It would be easy for a scammer to appear to know my card number. Once I got home, I was able to confirm that 4217 is, indeed, how most Bank of America debit card numbers begin.

Naturally I pressed 1 to “revalidate” my card (not-so-sidenote: you should not try this at home. Indeed, you really should just hang up when you get such calls). I wanted to see how this scam proceeded. At this point I was told a few more details explaining that my card beginning with 4217 needed to be revalidated because of a internal security failure and that I should press 1 to continue. I pressed 1 again.

I was then asked to enter my Bank of America debit card number. Unfortunately, I was not able to construct a number off of the top of my head that would pass their validation check.
While I knew it should begin with 4127 (thanks to the robocall), I did not know at the time that the next two digits should be between 64, 65, or 66 for Bank of America. I did know that the last digit of the sixteen digit number should be calculable from the preceding 15 digits by the Luhn checksum algorithm. But I couldn’t recall the details of the algorithm at the time, and I certainly would not have been able to construct something on the fly quickly enough to enter a “valid” number.

As a consequence, I wasn’t able to get past the “enter your debit card number” step, and so never learned what other information they would ask for, such as my Social Security Number, billing address, or PIN. But it is a safe bet that those would have been requested at some point. Those of course, would have been easier to fabricate as they have no quick validation system.

Checksums

The Luhn checksum is not some super secret security feature, it was a simple system designed to identify errors when exchanging credit card numbers in common use. At best, it can play a minor role in basic security checks to weed out those who just try random numbers.

The system is designed to catch common errors. If one digit of the 15 digits is entered incorrectly the checksum will fail. For example if the correct number is 4217 6601 2345 6784 (here 4 is the checksum) then if the number is given as 4217 6681 2345 6784, where the “0” has been mistyped as an” 8″, the check digit will be 7, and so  4217 6681 2345 6784, with a “4” as the last digit, will not validate.

Some people accidentally type “2435” instead of “2345”, swapping the “3” and the “4”. It happens to the best of us, and it’s another example of the the type of errors the Luhn system can catch.

Not all checksums are cryptographic hashes

1P logo in AESCheck digits of this sort, where the checksum is just one digit long, have properties that make them poorly suited for cryptographic purposes. The most obvious is that they are too small. That is, the check digit can only be one of ten possibilities—0 through 9. Put another way, there is a pretty much a 1 in 10 chance that two numbers will have the same check digit.

When two numbers result in the same checksum, we have a “collision”. If it is feasible to create two numbers that have the same check digit, the system is not collision resistant.

If we also have one number that has a particular checksum then we can easily construct another number that yields the same checksum. So the Luhn algorithm isn’t second-preimage resistant. The difference between collision resistance and second-preimage resistance is subtle. For collision resistance, the problem is “find two numbers whose checksums collide.” For second-preimage resistance, the problem is “here is a number m, now go and find another number that has the same checksum as m.”

It is also the case that if we have a checksum, we can easily construct a number that shares the same checksum. If you give me a checksum of “5”, I can construct a 15 digit number that has 5 as its checksum. That is, it is possible to work backwards from the checksum to an original. Hence, this checksum system is not preimage resistant. Functions that are preimage resistant are sometimes called “one way functions”.

The obvious reason why the Luhn algorithm fails to be preimage resistant, second-preimage resistant, and collision resistant is because it is just one digit. There just isn’t anything you can do when you only have one digit (about 3 bits) with which to work. But there are other reasons as well. I won’t discuss them at all, other than to say that the Luhn algorithm doesn’t have those three properties because it was never designed to.

Resistance is necessary

Cryptographic hash functions, however, are used for more than just checking for accidental errors in data entry or data transmission. This means they do need to be one way functions (preimage resistant); they need to be second-preimage resistant; and they really should be collision resistant.

We’ve discussed how preimage resistance is one of several essential properties of proper treatment of passwords on servers. We’ve also discussed how second-preimage resistance plays a vital role in network security. Over the next few posts I will be talking about how hash functions are used for data integrity checks and specifically for authenticated encryption. Authenticated encryption will play a big role in our next data format.

A fine night for a scam

I am relieved to say that both Patty and Molly did not really mind that I spent the remainder of our walk talking about the nature of the scam; how the criminals’ knowledge of the issuer number on a card can easily fool a target; and, of course, on the difference between checksums and cryptographic hashes. Lívia did not seem quite as complacent as the dogs. “The difference between us, Jeff,” she said, “is that I get really annoyed when something like that happens; but you seem to be really enjoying yourself.”

A few notes about robocalls

Robocalls are a lot like email spam:

  1. The caller ID number is easily counterfeited. You cannot rely on it to trace the source of the call
  2. “Press N to be removed from our list” is a lot like the “unsubscribe” button in email spam. Sure there may the the rare case where it is genuine, but usually it is just used to confirm that the spam/call reaches a real person who, to at least some extent, trusts the message. It’s a great way to get yourself added to more lists

As I write this, the US Federal Trade Commission is hosting a summit on robocalls. There should be more information at that site in coming days and weeks.

Correction October 22, 2012: I incorrectly suggested above that the Luhn algorithm will catch all single transcription errors involving the replacement of one digit with another and all cases where adjacent distinct digits are transposed. I was wrong. The ISBN checksum has these properties, but the Luhn Algorithm used for credit cards does not. The crucial difference revolves around the fact that the ISBN-10 system uses a prime modulus (11), while the Luhn system uses a composite modulus (10). This is also why the check digit for ISBN numbers can sometimes be “X”. The check digit there works out to be a number from 0 through 10, but “X” is used to indicate 10.

I should have spotted this instantly when I looked at the Luhn algorithm, but it required a different path for me to learn of my error. Today is a student holiday in our school district, and so I assigned my daughter the task of proving that the Luhn system will have the properties that I claimed it had. She quickly constructed some counter-examples, where changing an individual digit leads to the same check digit.

On Ars Technica’s most excellent comprehensive review of password security

Dan Goodin at Ars Technica published an excellent article reviewing password security and explaining why people need randomly generated and unique passwords for every site and service. That is a message you hear from us frequently.

One thing that is clear from Goodin’s review is that many of the underlying issues are more complicated than most people might think. There is a lot of stuff to learn and study to really get a handle on things. Some are technical (salts, hashing, rainbow tables) and others are human (people are actually terrible at constructing “random” passwords no matter how clever they think their scheme is).

I love studying this stuff, and I also love explaining these things to people. Indeed, I suffer from a pathological compulsion to explain things (though my family says that it is they who suffer from my compulsion). But we here at AgileBits also know that most sane people don’t want to have to learn all of the behind-the-scenes details just to be able to log on to websites securely, so we take a mixed approach. We design 1Password so that doing the easy thing is also doing the secure thing.

We also work to provide the behind-the-scenes details here on the blog for those who are interested. We love this stuff. It’s cool, and we like to share it. So the remainder of this post is an annotated list of some of our articles that cover the various topics that Dan wrote about. Often we go into more detail, or talk about things from a 1Password perspective.

Friends don’t let friends reuse passwords
Reusing the same password on multiple sites is probably more of a danger than actually having a less than perfectly strong password for the site. Indeed, I don’t think a week goes by when we don’t talk about password reuse. The particular article I single out here illustrates that real harm to real people can happen with password reuse. And of course it links to tips about how you can best use 1Password to have unique passwords for each site.
Toward better master passwords
Sure you are now using 1Password’s Strong Password Generator when you sign up for a new service or change a password on your site. After all, the only strong password is one that is randomly generated. But what do you do about setting your 1Password Master Password? You need to remember it, but it also should be strong (and thus randomly generated). This article helps you create a strong random password that will withstand the most sophisticated attacks even if your 1Password data falls into the wrong hands.
1Password is ready for John the Ripper
Dan Goodin’s article talked about password cracking tools, computer programs that guess enormous numbers of passwords. We look at how your 1Password Master Password would hold up against John the Ripper (it holds up very well, but you do need a good Master Password).
Tips, tips, and more tips
Once you get the hang of 1Password, there are a number of neat tricks and shortcuts that you can use to make life even more convenient. There are 1Click Bookmarks that can be used in almost any Mac app, some tips just for 1Password for Windows, some shortcuts for getting the most out of 1Password on iOS, quick ways to add software licenses on the Mac, and more. There are a lot of time saving tips in there, but learning multiple shortcuts at one time can be overwhelming. So come back to these, one by one, when you are ready.
Peanut Butter Keeps Dogs Friendly, too and A salt-free diet is bad for your security
Passwords, whether we are talking about your 1Password Master Password or a password on a website, need to be handled very carefully by systems. What the system stores should work to make it very very hard for someone who gets a hold of the data to be able to make use it. The first article describes PBKDF2, the password based key derivation function used by 1Password and other high security tools. The second article discusses how websites may or may not be doing a good job with when they manage your passwords.
Convenience is Security
When security tools go against the grain of how people work, the result is often poor security and unpleasantness. We bring top-notch security to people by paying attention to how people work. Our design goal has always been to make it easier for people to behave securely than to behave insecurely.

More than just one password: Lessons from an epic hack

Mat Honan, a 1Password user and writer for Wired, did everything right. He had strong, unique passwords everywhere. Yet he was the victim of an “epic hack”, and had to put a great deal of effort into getting his digital life back.

A very brief account of this Homer-worthy hack is that someone talking to Amazon customer service got into Mat’s Amazon account, from which they were able to learn enough about him to then call Apple’s customer service to get a new password set. Once they had Mat Honan’s Apple ID and password they used Remote Wipe to erase his iOS devices and his Macs.  This has been written about extensively elsewhere, but I would like to talk about this in the context of whether there are useful lessons for 1Password users.

Mat described part of his recover process thusly:

I’m a heavy 1Password user. I use it for everything. That means most of my passwords are long, alphanumeric strings of gibberish with random symbols. It’s on my iPhone, iPad and Macbook. It syncs up across all those devices because I store the keychain in the cloud on Dropbox. Update a password on my phone, and the file is saved on Dropbox, where my computer will pull it down later, and vice versa.

But I didn’t have it on any of our other systems. So now I couldn’t get to my keychain. And so I was stuck in a catch-22. My Dropbox password was itself a 1password-generated litany of nonsense. Without access to Dropbox, I couldn’t get my keychain. Without my keychain, I couldn’t get into Dropbox.

Lesson 1: Some might need more than one password

I love the idea that 1Password allows me to just remember one password, my 1Password Master Password. But some of us may actually want to remember a couple more. Here are the strong, unique passwords that I choose to remember:1Password in Dropbox

  1. My 1Password Master Password for the desktop
  2. My 1Password Master Password on my iOS devices
  3. My Dropbox password
  4. The passcode for my iOS devices
  5. My computer login password
  6. Password for my primary email account

Not everyone will have the same list. Plus, if you use the same Master Password on iOS as you do on the desktop, then your list is of course a little shorter.

What is relevant here is number 3 on that list. I need my Dropbox password in circumstances where I may not have access to 1Password. For example, when I start using a new computer, the first thing I install is Dropbox and the second thing is 1Password. This way, I have all of my 1Password data available to me as I go about setting up subsequent things.

Of course if I always had my phone with me, I could get my Dropbox password from 1Password on my phone, but I didn’t want to count on always having my phone. I’m guessing that this is what Mat did, and he certainly didn’t count on having his phone maliciously obliterated—along with all his other devices—via iCloud’s remote wipe feature.

Fortunately, Mat found a way back into his Dropbox account—turn out he had set up Dropbox on a machine that had not been wiped. So he was able to get to his 1Password data there, and begin to recover his digital life.

Constructing strong, memorable passwords

How do I make good strong passwords that I can also remember? I try to follow my advice in Toward Better Master Passwords. I have yet to follow my own advice with everything, but I am slowly migrating the few passwords that I do need to remember to that system. Indeed, it makes sense to change these gradually so that you are sure to have solidly memorized one new password before creating another that you need to remember.

A few more things I remember

In addition to the passwords that I feel I have to remember, here are a few things that are very convenient for me to remember instead of always looking up in 1Password. I can look them up if I really needed to, but often I need them where I can’t easily get them from 1Password:

  1. My bank card PIN
  2. My bicycle lock combination
  3. My Apple ID password
  4. My SSH private key password

I simply  haven’t figured out a way to copy and paste my bike lock combination from 1Password to the lock.

Lesson 2: Become a backup believer

There are two kinds of computer users: Those who have experienced a catastrophic disk failure and those who will.
— Ancient wisdom, source unknown.

First of all, making backups is essential. Today most people have two options for a backup system. We can go with off-site backups, or we can back up to a local disk. Backing up off-site is great protection if your house burns down or is burgled. You have put your eggs in different baskets. Backup to a local disk has the advantage that you aren’t depending on a remote service that you may not be able to access in an emergency. It is hard to make a case that one strategy is better than the other in general.

Here is something that Mat learned in the process.

I’m certainly a backup believer now. When you control your data locally, and have it stored redundantly, no one can take it from you. Not permanently, at least. I’ve now got a local and online backup solution, and I’m about to add a second off-site backup into that mix. That means I’ll have four copies of everything important to me. Overkill? Probably. But I’m once bitten.

But – and here is another reason to have a memorable Dropbox password – your online, off-site backup system will require a password to access. If you encrypt your at-home backups, those too will require a password to work from. Good backups are important, but you may need to get to your 1Password data before you can restore from a backup.

An old lesson: Don’t reuse passwords

Even if we take good care of our passwords, that doesn’t mean that all the sites and services that we use take the same care. Mat’s case illustrates this fact when it comes to password reset mechanisms, but it can also apply to how passwords are stored and encrypted on sites. Because not everyone handles things perfectly, we need to make sure to use unique passwords for each site and service.

Blizzard and insecurity questions: My father’s middle name is vR2Ut1VNj

By now most people will have heard that email addresses, hashed passwords, and some other data has been stolen from Blizzard’s Battle.net servers, and people are advised to change their passwords there. As unfortunate as this story is, it serves as yet another good reminder of why we very strongly encourage people to not reuse the same password on multiple sites and services.

One thing we don’t know yet is exactly how well hashed the passwords are. Blizzard EntertainmentFrom Blizzard’s announcement, we do know that the passwords were salted and hashed, but we don’t know whether it was simple salting (and how big the salt is) or whether they used something like PBKDF2. Their announcement tells us:

We use Secure Remote Password protocol (SRP) to protect these passwords, which is designed to make it extremely difficult to extract the actual password, and also means that each password would have to be deciphered individually

That tells us that the passwords were hashed and salted (see “A salt-free diet is bad for your security” for an explanation of what that all means). So Blizzard has certainly done a far better job in protecting users than, say, LinkedIn, which did not salt at all, but we don’t know exactly how much better. Unless I have misunderstood something, I believe that their use of SRP, while cool and good for some purposes, is not relevant to this particular case.

It’s the security questions that worry me

The Blizzard data theft also includes “the answer to the personal security question”. This is a bigger problem because even people who are careful to not reuse the same password at multiple sites may provide the same answers to “security questions” everywhere.

We’ve all seen – and probably made use of – schemes on websites that will let you reset your password if you can answer a few security questions (I’ll drop the scare quotes from here on out, no matter how poorly I think the name fits what they do). These questions are typically things like your mother’s maiden name or street where you lived when you were 10 years old.

Not good secrets

In March 2010 someone going by the handle “Hacker Croll” gained control of President Obama’s and other celebrities’ Twitter accounts by “simply working out the answers to password reminder questions on targets’ e-mail accounts” according to the BBC. It was neither the first nor the last time that so-called security questions have been used to compromise accounts. Quite simply, the information in these questions and answers are not really very secret. Parents’ names, for example, are available on birth certificates (which are a matter of public record in many places) and other information can often be gleaned with a bit of research. In the case of people who’ve written auto-biographies, the information can be all in one place.

They encourage reuse

The point of security questions is that they are something that the user can remember because they are true things that the user knows; it is exactly that which makes them easy to guess. If my father’s middle name is Walter, then that is what I would normally answer every place that I am asked.

Naturally, the whole problem is solved if you don’t have to remember your security questions and answers yourself—you can just let 1Password do the remembering for you. I’ll get back to that later, but first I’d like to point out a couple of other points (beyond guessability and reuse) about why being careful even with security questions is also so important.

Too Much Information

You, for whatever reason, may not wish to let the world know what your father’s middle name is. Yet security questions may ask you to provide exactly the sort of information you would rather not share. Although I may not consider a particular bit of personal information to be sensitive or confidential, you may very legitimately feel otherwise.

Reasonable people can disagree about whether they feel that revealing their father’s middle name is too much information. But I think that we will all agree that “your preferred Internet password” is far too much to ask. Our friends over at 37signals, reporting on what they found when setting up an account on some site.

World's worst challenge question

As you can see, one of the challenge questions is “What is your preferred internet password?” When Roustem pointed this one out to me, I was truly at a loss for words, which is not something that happens very often.

Not stored well

The security questions are never stored more securely than your password for the site, and often they are handled far less securely. As noted above the (unencrypted) answers to Blizzard security questions were stolen. It really isn’t surprising that these things aren’t encrypted or hashed well. Often your security questions and answers are visible to people who work for the organization. Armed with the knowledge that a human may well see the security question and answer, some people have suggested (in the comments) clever (and often profane) texts.

Strong and unique answers with 1Password

Instead of telling the site the real name of your first pet, use the 1Password’s Strong Password Generator to create a random and unique name for that pet and store that information in the Login entry in 1Password. It may be tempting to use the same random and unique password that you use for the site, but there are a couple of reasons not to do that. I’ve already mentioned the first reason: These security question responses are not stored as securely as passwords; they might appear in email or be given out over the phone. The second reason not to use your site password as your security question answer is that if you change your password for a site, you are likely to forget to update the security question as well. This can leave you with a site security question that you have no record of and no way to remember. (I have learned this from experience.)

1Password does many things automatically for you, but this isn’t one of them, so you will need to help 1Password along to get this information stored properly. There are two things that 1Password will need help with. The first is that the strong password generator only fills password fields, and so can’t automatically fill most security question fields. The second is that you will need to add the security question and answer to a note within your Login.

I’ve spoken with my friends here, and it seems like we all have our own different work flows for handling this. I will step through the way that I do this.

1. Save the Login first

JSE save Login

Before we go about getting getting an answer for a security question, we need to make sure that the Login for the site exists within 1Password.. So I will save the new Login from the browser extension, even if I don’t yet have the security question part filled out. Remember that you can save a Login with data you have filled out on a form before you actually submit the form. Just go the the browser extension and click on the “+” button in its upper right corner. (Or on Windows, depending on your browser, use the “Save” button.)

2. Invoke the Strong Password Generator

I like to invoke the Strong Password Generator from the 1Password application itself when dealing with security questions. So I open and unlock 1Password Application and go to File > New Item > New Password from the menubar.
This will open up the Strong Password Generator. (It is important to launch it this way, because if you use the “generate” button within an item, the Generator will replace an existing password.)

Invoke generator

In 1Password for Windows, you can launch the Strong Password Generator through Internet Explorer browser extension. For other browsers, I recommend getting to the Strong Password Generator through the application itself using File > New Item > New Password.

Strong Password Generator on Windows

3. Generate and Copy a new password

The Strong Password Generator will save the passwords that it creates in the Generated Password Vault, so if you ever need to go hunting for this one there (you shouldn’t have to, but it’s a good to know it’s in there), you should set a useful Title for your Generated password. In my example below I have that as “Security question for example.com”.Generator

In some cases the answers to security questions are meant to be read by humans. For example, it may need to be asked about during a telephone conversation as part of a password recovery process. In these cases, it may be useful to use the Advanced Options in the Generator to select a pronounceable password.

We will need to make sure that the generated password gets copied to the clipboard. You can do this either by clicking on the “Copy” button or making sure that the check box is set by “Copy password to clipboard on completion. Then you can Save this item to your Generated Passwords vault.

4. Paste the generated stuff into the notes field in the Login

Now we need to find and edit the Login for the site to include both the security question and your newly generated random answer.
Paste note into JSE
You can do this either within the browser extension (on the Mac or in the Safari extension on Windows) or within the Application. In the browser extension, just search for the Login, click the little arrow at the right, and then the Edit button.

In my example the Strong Password Generator gave me vayt-jebs-yaf-g, so I paste that into the notes field in the Login along with the question. After I save the Login, my notes field for the login will say “First pet: vayt-jebs-yaf-g”.

One point I should make here is that I store these in the “notes” within a Login (instead of within custom fields) because notes will be preserved if the Login is updated later in the browser. Form fields will be replaced on such an update.

5. Paste security answer into the web form

Now that we have everything squared away within 1Password, we need to make sure that the website asking the security question knows that your pet’s name is vayt-jebs-yaf-g. So you will need to paste that information into the web page as your answer to the security question.

At your finger tips

The principle purpose of security questions is for password recovery. It’s what you are supposed to use if you forget your password. With 1Password you shouldn’t have to worry about forgetting a password for a site because 1Password remembers it for you. However, if you do store security questions and their answers within 1Password, you must take extra care to ensure that you never lose access to your 1Password data. You are storing your passwords and your password recovery secrets in the same (highly secure) basket.

Being more helpful

We clearly need to look at how we can make 1Password be more helpful in this process. We’ve been hoping that “security questions” would just go away, but it looks like this practice will be around a a while. As always, we never (well, hardly ever) talk about features until they are delivered, so no promises.

I’d love to hear what other solutions and ideas our users have for handling these. So please join the discussion of this post in our forums.

Updated: 13:30 EDT August 10 to correct instructions for using 1Password for Windows.

Password reuse strikes again, and a bit closer to home at Dropbox

1Password in DropboxNot so long ago, I wrote about a case where attackers were taking passwords that were leaked from one site to go after users on another. In that case, the target was Best Buy. Today’s case hits a bit closer to home for 1Password users, as Dropbox accounts are being attacked using passwords stolen from non-Dropbox sites. Just as no passwords were stolen from Best Buy, no passwords have been stolen from Dropbox. The passwords were stolen from breaches at other sites and then just applied to Dropbox accounts.

To give you an idea of the dangers of password reuse and how this type of attack works: suppose Molly has an account on chasing-cute-cats.com and that site got breached. Also imagine that the site didn’t store passwords in sufficiently secure ways, so that after the breach it was possible for attackers to actually figure out what many users’s passwords, including Molly’s, are. The attackers now have Molly’s username and password on that site. You might figure that there is little harm done because there really isn’t a lot that people could do with Molly’s account on chasing-cute-cats.com.

But now suppose that Molly uses the same username and password on Dropbox (Molly doesn’t take advice all that well). The attackers can try to log into Molly’s Dropbox account with the username and password they discovered from the breach at chasing-cute-cats.com. This, according to the recent announcement by Dropbox, has been going on with a small number of Dropbox accounts.

Users of 1Password probably don’t need to be reminded why it is so important to have unique passwords for every separate site and service. But because this case of password reuse with Dropbox is such a good reminder, it can’t hurt to talk about it again in the hopes we can all help spread the word.

Of course, even if someone were to get a hold of your 1Password data through Dropbox or some other means, they would not be able to get your usernames, passwords, and other data stored within it without knowing your 1Password Master Password. But this is why we designed the 1Password data format with the knowledge that some people may have their data files stolen. Indeed, just yesterday I wrote (in gory detail) just how well 1Password and your Master Password work together to resist even the most sophisticated password cracking tools.

Irony, spam, and discovery

Mail things this message is spam

One of the accounts broken into that way belonged to a Dropbox employee.
It turned out that that the unnamed (but presumably very embarrassed employee) also had some files that included the usernames (which are email addresses) of some Dropbox customers. Naturally, the attackers did what attackers do when they get a hold of a bunch of email addresses: they passed (presumably sold) that list to spammers.

Again, it was only the email addresses that got taken; not passwords. But then, spam went out to a number of Dropbox users, some of whom had set up site specific email addresses. For example, Patty may have created an email address patty+dropbox@example.com that he used only for Dropbox. Nobody knew or ever saw that email address except for Patty and Dropbox.

But if Patty+dropbox@example.com was among the email addresses stolen and passed on to spammers, Patty would start getting spam to that address. Patty, being the clever one, would realize that somehow her Dropbox email address had been captured. She might even complain to Dropbox about this, along with a few others who have suddenly seen spam to their Dropbox-only email address.

And now we arrive at the beginning of the story. It was exactly complaints like this that led Dropbox to bring in an outside security investigator to look at the spam issue back on July 18.

What have we learned and what is there to do?

Molly is afraid of ThunderFirst of all, we have been reminded yet again that Molly is not as clever as she thinks she is, while Patty shows an abundance of caution (sometimes too much). Now, regular readers of my posts will know that Molly and Patty are my dogs. Molly, while incredibly sweet, wins few prizes for intelligence. Patty is much brighter, but is always on high alert and will fire off a warning bark if a molecule moves across the street. There is a lesson somewhere in here about learning to be cautious about the right things. Panicked people (and dogs) tend to make poor security decisions, but that discussion is for another time. All we need to say here is that Molly, as presented above, needs to have a unique password for each site.

Patty barks at everything

We are also reminded that one site’s security is dependent in some ways on other sites. The operators of chasing-cute-cats.com might think that they don’t need to be particularly careful with their users’ passwords, but they are wrong. As long as people (or dogs) reuse passwords, it is the responsibility of everyone who stores passwords to store them in uncrackable forms.

Furthermore, because so many websites and services are storing passwords poorly, we all need to act as if our website passwords are stored poorly at each site. As we’ve been reminded by an ongoing case involving Tesco (a large UK grocery chain and retailer in the UK and Europe), its generic statements like “passwords are stored in a secure way” are meaningless unless we are told how they are encrypted.

How many passwords do I need to remember?

I would love to be able to say that with 1Password you only need to remember your 1Password Master Password. It’s in the name. 1Password does the job of remembering all of the other non-memorable passwords. After all, Troy Hunt is largely right when he says that the only secure password is the one that you can’t remember. But the first thing I do when I set up a new computer is install Dropbox to sync my 1Password data, and then install 1Password. There are times when I need to know my Dropbox password in order to be able to use 1Password. So, despite the name, I actually need to remember two strong, unique, and, this time, memorable passwords.

Fortunately, you and I can use the mechanism described in Toward Better Master Passwords to be able to manage the very few passwords that we actually need to remember.

1Password is Ready for John the Ripper

John the Ripper, the pre-eminent password cracking tool, is getting ready to take on 1Password. Is 1Password ready? Yes! We have been ready for a long time, but you need to do your part by having a good Master Password.

We’ve written many times about how 1Password defends against automated password guessing programs (password crackers). And we’ve been strengthening those defenses as well. If you’ve been wondering why we’ve been devoting so much effort to this, well this is the article for you.

We’ve always known that that there is nothing we can do prevent someone developing an automated Master Password guessing tool that is tuned to 1Password data, and so we’ve designed our security around the assumption that such tools do exist. What we can do (and have done) is make any password guessing program work extra hard, so that it can only guess thousands of passwords per second instead of many millions per second. We also have been advising people to make sure that their 1Password Master Passwords are strong, unique, and memorable.

What’s new

Password crackers don’t break the cryptography or exploit bugs or design weaknesses. They are just programs that try millions or billions of different passwords until they either find one that works or the person running the program gives up.

John the RipperThe news is that the most popular and sophisticated open source password cracking tools available, John the Ripper, is now being adapted toward cracking password managers Master Passwords. More recently (July 25) we see the development of tools specifically designed for making John the Ripper work with 1Password’s Agile Keychain Format.

John the Ripper expects the data that it works with to be in particular formats. The modifications to John the Ripper for 1Password involve two components. One converts the relevant part of the Agile Keychain Format into an appropriate input file, and the second part allows John the Ripper to test against that input file in a way that allows it to recognize a successful guess.

Let me stress again that the existence of a password cracking tool does not reflect any kind of weakness in the system it is attacking. When you have encrypted data, there is nothing stopping a person or a computer from trying to guess the password.

What’s not new

Other than repeating the fact that 1Password users should have a unique, strong, and memorable Master Password, there is nothing that we need to do with 1Password in response to the new components of John the Ripper. We have been operating under the assumption that these sorts of tools already existed, even if they hadn’t been made publicly available.

PBKDF2 diagramWhen we introduced the 1Password data format in 2008, we knew that we needed to design it to defend against crackers, so we used PBKDF2 in the process of getting from Master Password to encryption key. PBKDF2 means that a computer has to do many complicated and slow computations to derive an encryption key from a password. So you might have to wait half a second or so after entering your master password for 1Password to actually be able to unlock your data, but that is barely noticeable to someone using the system. But for an automated password cracking system, it dramatically reduces the number of possible passwords it can guess in a day. We’ve written more about how PBKDF2 works in Peanut Butter Keeps Dogs Friendly, too. Plus, last year we increased the number of PBKDF2 iterations that many versions of 1Password use when creating a new data file.

We have also been encouraging people to use good Master Passwords for their 1Password data. 1Password means that your various login passwords don’t need to be anything that you need to remember (and so it is easy for those to be strong and unique), but your 1Password Master Password is something that needs to be strong, unique, easy to remember, and reasonable to type. There is a great deal of advice on the ‘net about how to pick a good password that you can remember, but much of that advice fails to take into account the flexibility of password cracking tools. So please take a look at Toward Better Master Passwords if you haven’t already looked at that.

How fast in John the Ripper and what does it mean for your master password?

I’ve spent much of the weekend playing with the new tools in the developer versions of John the Ripper.CPU cores are completely pegged I ran John the Ripper (JtR) against my 1Password data for about 20 minutes on my Early 2009 Mac Pro (Quad Core). John the Ripper cranked away and consumed more CPU power than I knew my machine had (see picture at right). Yet working against a 1Password data file that used 1000 PBKDF2 iterations, JtR was only able to try about 4200 password guesses per second. For my calculations in the table below, I rounded that up to 5000 guesses per second.

I also tested a data file with 28,000 PBKDF2 iterations. As expected John the Ripper was slowed down about 28 times from the case with 1000 PBKDF2 iterations.  In the table I provide estimated cracking times if the data file uses 25000 PBKDF2 iterations, which should make JtR run about 25 times slower than when there are 1000 iterations. (Again, my timing data was a bit messier, but I am always rounding toward the worst case. That is, whenever there is some ambiguity or a range of results, I am always picking the estimates that would have John the Ripper be faster.)

The author of the 1Password plug-in, Dhiru Kholia, anticipates that the module will soon be modified so that it can make use of Graphic Processor Units (GPUs). This, he estimates, will increase the guessing speed by more than 100 times. In my table below, I have used a 200 times increase in speed for GPUs. So that where I had roughly 5000 guesses per second on my Mac Pro, I assume that with GPU acceleration, there will be one million guesses per second.

Mac Pro (Early 2009)And finally to read the table below, you need to be reminded of how I am measuring password strength. I can only calculate the strength of a password if I know the system by which the password was created. A great deal of advice floating around about creating passwords fails to take into account that the attackers know more about how people create passwords than the people creating the passwords, and these attackers can and do tune their cracking tools accordingly. Much of the common advice also fails to take into account that people are far more predictable than we imagine. So passwords that may look really strong are often far weaker than people imagine.

If you read the advice in Toward Better Master Passwords, you will see that the recommended system is to pick words from a list truly at random (by rolling dice) and then just using that sequence of randomly chosen words as your Master Passwords. This sort of system, until it became the subject of an xkcd comic, was known as diceware.

The table below looks at Master Passwords 3, 4, 5, 6, and 7 diceware words long. The entropy of those passwords are listed in bits. For an explanation of what “bits of entropy” means, take a look at The Geek Edition of the article on better master passwords.

The cracking times are the average or mean time to crack. For example if it would take 116 years to try every possible 4 word password created with the diceware scheme, then it would take on average 58 years.

JtR crack times for agilekeychain

Lessons

From the table you should surmise that three-word-long passwords of this sort aren’t long enough to withstand a plausible attack. You should also be able to see that anything over five words long is overkill. Or, given a Master Password with more than about 55 bits of real entropy (not the false reports that you get from most websites pretend to calculate password strength), you should be fine against any plausible attack for a long time to come.

PBKDF2 and its limits

It really is because of PBKDF2 that tools like John the Ripper will only be able to find weak Master Passwords. Its role is vital. But it is important to notice that once we have a sufficient number of PBKDF2 iterations, increasing those doesn’t add that much additional security. Going from 1000 iterations to 25000 iterations is the equivalent of adding less than 5 bits of entropy to a password, which is about the same as adding a truly random, lowercase letter to a password. Furthermore, there are continuing diminishing returns: Going from, say, 25,000 PBKDF2 iterations to 50,000 would only add the equivalent of one bit of entropy to a password.

In short, once PBKDF2 is in place with a reasonable number of iterations, you get far far more security for the effort by making your Master Password stronger.

Why doesn’t 1Password limit the number of password attempts?

Many websites or an ATM will lock someone out if they enter their password incorrectly too many times. Websites will also have a kind of back-off. After you’ve entered your password incorrectly three times in a row, it may make you wait ten minutes before it lets you try again. These are very good security measures for those sorts of services. So the question is: why don’t we do the same with unlocking 1Password?

1Password stores your encrypted data on your computer. You may use Dropbox for syncing, but when 1Password does its thing, it is always unlocking data that is on your computer. This means that if an attacker gets hold of your 1Password data (say your computer is stolen), they have the data right there. They do not need to use the 1Password software, they can go directly to the data with their own tools. Because an attacker doesn’t have to go through our software or systems we control, there is no place for using using throttling or back-off techniques. We have to build the security into the data format itself. Our use of PBKDF2 is an example of that.

More abstractly and to introduce a bit of technical jargon, your Master Password is an encryption password, not an authentication password. It is used as (or to derive) a key that decrypts something. It is not used as a mechanism to prove who you are so that you could be let into some service. The distinction is subtle, and particularly prone to confusion because, for the most part, a user shouldn’t have to know or care about it. But there are a couple of places where the distinction matters. It is part of the explanation for why 1Password doesn’t do back-off or throttling.

There is one other place that the distinction between encryption password and authentication password matters for users of 1Password. I will be writing about it more later, but in summary: it means that once you have a good 1Password Master Password, you should keep it for life. You gain no security by changing an encryption password frequently (indeed, it can hurt). So you should only change your 1Password Master Password if there is something wrong with your current one. I’ll talk more about changing passwords (when you should and when you shouldn’t) in a future article.

Should we keep our data format secret?

It’s natural to ask whether we could have made things harder for the developers of password cracking tools if we weren’t as open as we are about the design of our data format. We certainly could have made things a bit more annoying for them if we attempted to conceal details of our data format, but we couldn’t have made things harder for them in a way that would have mattered for security.

On the whole, people should be distrustful of systems that claim to gain security by having secrets known only to the developer. That approach is often called security through obscurity. It not only rarely works, but it often implies a weakness in the design. For example, if there were something that I knew about the design of 1Password that would enable me to unlock your data, then it would necessarily be the case that there is a weakness in the system. Such secrets can often be discovered by careful analysis or through the secret actually getting out from those who know it. Despite what I may have said on April Fool’s Day, proprietary encryption systems are a warning sign, not a virtue.

Join the discussion

I have set up a specific discussion thread on our forums for further discussion. Please join us there.

Friends don’t let friends reuse passwords

We’ve written about password reuse before, and we’ll be writing about it again. Password reuse—using the same password for multiple sites or services—is both rampant and dangerous.

There is real evidence that people are getting robbed because they are reusing their passwords. Thieves systematically exploit reused password to pay for retail items or hijack accounts for other intentions. And yet, we are reminded again this week by the recent leak of almost half a million Yahoo passwords that a majority of people just can’t stop reusing passwords.

I’ve seen password reuse and the damage done

Suppose you used the same password on Sony’s PlayStation Network as you Best Buyuse for your password when shopping with Best Buy. Now, suppose that your PSN username and password was among the 77 million leaked in April 2011. An attacker could, in principle, use that information to take a good guess at your password for, say, Best Buy.

Well this isn’t just something that can happen “in principle”. From an underappreciated report by John Fontana over at ZDNet:

After months of Best Buy customers reporting compromised accounts, the company has finally confirmed hackers are attacking its online retail site using credentials stolen from other sites.

It’s a worst-case scenario, where credentials stolen from one site are used to access other sites, most notably retail or banking sites where hackers can extract some value.

I have no doubt that things like this have been going on for a while, but it is always hard to confirm that this is what has happened when someone “hacks” a users account at a retail site. So let there be no doubt that password reuse puts people into real danger. It happens.

Some habits are hard to kick

Sites and services that store user passwords unencrypted or poorly hashed are a serious danger to their customers. But when they get breached and their password database made public, it is a boon to people who study password security. One of those people is Troy Hunt, who has taken this as an opportunity to look at password reuse between PSN and Yahoo.Chart of PSN-Yahoo password reuse

Of the 302 usernames in common between the two breaches, 59% of them had the same password on each site. Note also that the PSN breach was more than a year ago and was very widely reported. Put simply, we can estimate that about 60 percent of people ignore advice to change their passwords elsewhere.

Helping you to help yourself

I’ve argued many times before that when we see people systematically making poor security choices, we can’t just blame the user. We—the security business—have to look at how we can make it easier for people to behave securely. 1Password is our attempt at fulfilling that goal. We work to make it easy for people to have strong and unique passwords for each site.

First of all, 1Password provides you with a Strong Password Generator, in both the app itself and the 1Password browser extension. This generator makes it drop-dead-simple to create website passwords that are strong and unique. Plus, you don’t need to remember them because 1Password remembers them for you.

Although 1Password wasn’t born yesterday, many of us have Logins and passwords for sites that were created before we had the Strong Password Generator, which means we may still be using some passwords on multiple sites. Here are some tips on how to use 1Password to help you find duplicate password and clear those up.

Websites have responsibilities, too

Anybody who stores your passwords has responsibilities, too. We know that sites get compromised and their user databases stolen. What we don’t really know is how frequently this happens because only a fraction of those breaches get made public. Not only do websites and services need to take steps to prevent the theft of their user’s personal data, they need to store the passwords in a form that is useless to intruders.

It appears that the Yahoo passwords were stored with no encryption or hashing at all. I was astounded when this was discovered with Sony’s PSN last year, and I am astounded today that Yahoo would make the same mistake. I have been berating sites for not hashing their passwords well; I hadn’t expected to encounter more sites that didn’t hash at all. Because of their poor practice, everyone whose Yahoo password was leaked is vulnerable to having their accounts hijacked on every other site where they use the same password.