Don’t trust a password management system you design yourself!
by Jeffrey Goldberg on
Nicole Perlroth of The New York Times penned an article on “How to Devise Passwords That Drive Hackers Away“. The article has a typical mixture of good advice that could often be better, along with some implied advice that I actually consider very poor.
The two security experts that Perlroth cites – Jeremiah Grossman, an expert on website security and founder of WhiteHat Security, and Paul Kocher, a noted cryptographer and founder of Cryptography Research – express some skepticism about password managers. They give a number of different reasons for their skepticism that are worth dissecting.
From the article:
Mr. Grossman stores his password file on an encrypted USB drive for which he has a long, complex password that he has memorized. He copies and pastes those passwords into accounts. […] Mr. Grossman said he did not trust [password management software] because he didn’t write it.
There is a very, very small handful of people who can get away with saying that they will only trust a password management system that they build themselves, but you should definitely not trust a password management system that you develop yourself.
There are broad challenges to consider and questions to ask when developing a password management system, and we’ve covered a number of them here on the Agile Blog. These requirements hold true even if that system is to “just use a file or disk encryption software”:
What is your source of randomness for key and password generation? Do you know how to use a cryptographically secure random number generator and why it works the way it does?
What is your key derivation function? Does it use something like PBKDF2 to resist password cracking attempts?
How much sensitive data remains decrypted at any one time? If you decrypt an entire file, then all of that decrypted data will need to reside in memory or virtual memory on your computer, leaving it potentially exposed after a crash, in memory, in automatic backup files, or in system swap files.
What measures does the system have to prevent data loss? Does the (automatic) back up system perform any integrity checks on the data prior to making a backup?
How is memory of sensitive data cleared when it is no longer needed?
Are there obfuscation techniques for sensitive data (such as decryption keys) that may need to reside in the app’s memory for a while?
Will your system automatically lock or does it require you to take action to lock/close your data?
Can you eliminate or minimize the use of Copy and Paste of sensitive data?
And most importantly, can you keep up with all of the research and development on all of these (and other) issues that may require a change in design or implementation? As an example, 1Password has been updated 178 times since its debut in 2006.
Those are just a few of the things that someone needs to be able to address when developing a password management system on their own. Most importantly, this list applies even if you develop no software yourself. Even using a very well designed file or disk encryption tools doesn’t address many of the security requirements of a good password manager.
I emphatically need to point out is that keeping your passwords in an encrypted file or on an encrypted disk volume still counts as a home grown password management system. And so it appears that Grossman has designed his own password management system, possibly without recognizing that he has done so. He very well may have designed a good system for himself, but I would discourage people from trying to develop their own systems.
I had tried to develop my own password management system prior to settling on 1Password in early 2007. It involved GPG file encryption, a wrapper for vi which prevented it from writing back-up files, and preventing core dumps in case of a crash. But utimiately my little home grown system was neither satisfactory nor easy to use.
I then went on a serious search for a password management system that would satisfy my growing list of requirements. 1Password was by far and away the best password manager on the Mac, and the more I learned about how it addressed requirements and topics that I hadn’t even considered at the time, the happier I became.
Another issue that Grossman raises about password managers is that some of them are poorly designed and implemented. This does make it hard for people trying to trust a password manager. Most people are not in a position to determine for themselves which ones are well designed and which aren’t. Our openness in describing and documenting these details in 1Password should offer confidence that 1Password is well designed. The respect that we’ve earned among the expert community should offer even more.
The article cites some of the research behind Elcomsoft’s scathing review (PDF) of password managers on mobile devices, which we wrote about last March. That report did included some issues in 1Password on iOS (which we quickly addressed), but it also shows that there is enormous variation in the quality of password managers. 1Password is clearly among the best.
I’d have to do too much reading between the lines to try to figure out precisely what the concern is, but possibly it is the concern that a password manager keeps all of ones eggs in one baskets. From the outset, we designed the 1Password data format with the assumption that some people would have their computers stolen. In other words: your 1Password data needs to be able to stand up to serious attempts to crack it. In particular, we’ve made it very, very difficult for password cracking systems, such as John the Ripper, to recover your Master Password.
The small risk of putting all of your eggs into the 1Password basket is enormously less than not using a password manager at all. Without some sort of password management system (whether home-grown or not), people will end up reusing the same weak password for multiple sites and services. We’ve written extensively about the problem of password reuse, so I won’t repeat it here.
The New York Times article gave another piece of advice, separate from its comments about password managers, that I must also address. When advocating passphrases (a good idea for passwords you need to remember) Perlroth advises:
Because longer passwords tend to be harder to remember, consider a passphrase, such as a favorite movie quote, song lyric, or poem, and string together only the first one or two letters of each word in the sentence.
Don’t do that. This password creation scheme, and every other, is well known to those who develop and use password guessing programs, so there have long been tools designed to guess these kinds of passphrases. Indeed, KoreLogic‘s most recent Crack Me If You Can competition included a set of challenges that specifically went after passphrases based on quotations.
In general we should assume that attackers know at least as much about password creation schemes as the people using such schemes. So the only good password creation mechanism is one where knowledge of the system used to create the password or passphrase does not render the password crackable. This is why your passwords should be randomly generated. For passwords that you don’t need to remember – 1Password remembers them for you – 1Password’s Strong Password Generator is the tool to use.
For your 1Password Master Password, the one password you do need to remember (or at least among the very few passwords you need to remember), please consider my advice in “Toward Better Master Passwords“. It will give you strong and memorable passwords that remain strong even when the attacker knows what system you used.
[Updated to give accurate statement about Grossman’s and Kocher’s background and expertise]
[Update 2: The New York Times posted a followup, which cites this article, and allows for discussion.]