In previous articles, we have looked at how to generate
passwords and did a review of various
password managers. There is, however, a
third way of managing passwords other than remembering them or
encrypting them in a "vault", which is what I call "password hashing".
A password hasher generates site-specific passwords from a single master
password using a cryptographic hash function. It thus allows a user to
have a unique and secure password for every site they use while
requiring no storage; they need only to remember a single password. You
may know these as "deterministic or stateless password managers" but I
find the "password manager" phrase to be confusing because a hasher
doesn't actually store any passwords. I do not think password hashers
represent a good security tradeoff so I generally do not recommend their
use, unless you really do not have access to reliable storage that you
can access readily.
In this article, I use the word "password" for a random string used to
unlock things, but "token" to represent a generated random string that
the user doesn't need to remember. The input to a password hasher is a
password with some site-specific context and the output from a password
hasher is a token.
What is a password hasher?
A password hasher uses the master password and a label (generally the
host name) to generate the site-specific password. To change the
generated password, the user can modify the label, for example by
appending a number. Some password hashers also have different settings
to generate tokens of different lengths or compositions (symbols or not,
etc.) to accommodate different site-specific password policies.
The whole concept of password hashers relies on the concept of
one-way cryptographic hash functions
or key derivation functions that take an arbitrary input string
(say a password) and generate a unique token, from which it is
impossible to guess the original input string. Password hashers are
generally written as JavaScript bookmarklets or browser plugins and
have been around for over a decade.
The biggest advantage of password hashers is that you only need to
remember a single password. You do not need to carry around a password
manager vault: there's no "state" (other than site-specific settings,
which can be easily guessed). A password hasher
named Master Password makes a compelling case against traditional
password managers in its documentation:
It's as though the implicit assumptions are that everybody backs all of
their stuff up to at least two different devices and backups in the
cloud in at least two separate countries. Well, people don't always
have perfect backups. In fact, they usually don't have any.
It goes on to argue that, when you lose your password: "You lose
everything. You lose your own identity."
The stateless nature of password hashers also means you do not need to
use cloud services to synchronize your passwords, as there is
(generally, more on that later) no state to carry around. This means,
for example, that the list of accounts that you have access to is only
stored in your head, and not in some online database that could be
hacked without your knowledge. The downside of this is, of course, that
attackers do not actually need to have access to your password hasher to
start cracking it: they can try to guess your master key without ever
stealing anything from you other than a single token you used to log
into some random web site.
Password hashers also necessarily generate unique passwords for
every site you use them on. While you can also do this with password
managers, it is not an enforced decision. With hashers, you get distinct
and strong passwords for every site with no effort.
The problem with password hashers
If hashers are so great, why would you use a password manager? Programs
like LessPass and Master Password seem to have
strong crypto that is well implemented, so why isn't everyone using
those tools?
Password hashing, as a general concept, actually has serious problems:
since the hashing outputs are constantly compromised (they are sent in
password forms to various possibly hostile sites), it's theoretically
possible to derive the master password and then break all the
generated tokens in one shot. The use of stronger key derivation
functions (like PBKDF2, scrypt, or HMAC) or seeds (like a
profile-specific secret) makes those attacks much harder, especially
if the seed is long enough to make brute-force attacks
infeasible. (Unfortunately, in the case of Password Hasher Plus,
the seed is derived from Math.random() calls, which
are not considered cryptographically secure.)
Basically, as stated by Julian Morrison in this discussion:
A password is now ciphertext, not a block of line noise. Every time you
transmit it, you are giving away potential clues of use to an attacker.
[...]
You only have one password for all the sites, really, underneath, and
it's your secret key. If it's broken, it's now a skeleton-key [...]
Newer implementations like LessPass and Master Password fix this by
using reasonable key derivation algorithms (PBKDF2 and scrypt,
respectively) that are more resistant to offline cracking attacks, but
who knows how long those will hold? To give a concrete example, if you
would like to use the new winner of the password hashing competition
(Argon2) in your password manager, you can patch the program (or
wait for an update) and re-encrypt your database. With a password
hasher, it's not so easy: changing the algorithm means logging in to
every site you visited and changing the password. As someone who
used a password hasher for a few years, I can tell you this is really
impractical: you quickly end up with hundreds of passwords. The
LessPass developers tried to facilitate this, but they ended up
mostly giving up.
Which brings us to the question of state. A lot of those tools claim to
work "without a server" or as being "stateless" and while those claims
are partly true, hashers are way more usable (and more secure, with
profile secrets) when they do keep some sort of state. For example,
Password Hasher Plus records, in your browser profile, which site you
visited and which settings were used on each site, which makes it easier
to comply with weird password policies. But then that state needs to be
backed up and synchronized across multiple devices, which led LessPass
to offer a service (which you can also self-host) to keep those settings
online. At this point, a key benefit of the password hasher approach
(not keeping state) just disappears and you might as well use a password
manager.
Another issue with password hashers is choosing the right one from the
start, because changing software generally means changing the algorithm,
and therefore changing passwords everywhere. If there was a
well-established program that was be recognized as a solid cryptographic
solution by the community, I would feel more confident. But what I have
seen is that there are a lot of different implementations each with its
own warts and flaws; because changing is so painful, I can't actually
use any of those alternatives.
All of the password hashers I have reviewed have severe security
versus usability tradeoffs. For example, LessPass has what seems to be
a sound cryptographic implementation, but using it requires you to
click on the icon, fill in the fields, click generate, and then copy
the password into the field, which means at least four or five actions
per password. The venerable Password Hasher is much easier to
use, but it makes you type the master password directly in the site's
password form, so hostile sites can simply use JavaScript to sniff the
master password while it is typed. While there are workarounds
implemented in Password Hasher Plus (the profile-specific secret),
both tools are more or less abandoned
now. The Password Hasher homepage, linked from the extension page,
is now a 404. Password Hasher Plus hasn't seen a release in over a
year and there is no space for collaborating on the software — the
homepage is simply the author's Google+ page with no information on
the project. I couldn't actually find the source online and had to
download the Chrome extension by hand to review the source code.
Software abandonment is a serious issue for every project out there,
but I would argue that it is especially severe for password hashers.
Furthermore, I have had difficulty using password hashers in unified
login environments like Wikipedia's or StackExchange's single-sign-on
systems. Because they allow you to log in with the same password on
multiple sites, you need to choose (and remember) what label you used
when signing in. Did I sign in on stackoverflow.com? Or was it
stackexchange.com?
Also, as mentioned in the previous article about password managers,
web-based password managers have serious security flaws. Since more
than a few password hashers are implemented using bookmarklets, they
bring all of those serious vulnerabilities with them, which can
range from account name to master password disclosures.
Finally, some of the password hashers use dubious crypto primitives
that were valid and interesting a decade ago, but are really showing
their age now. Stanford's pwdhash uses MD5, which
is considered "cryptographically broken and unsuitable for
further use". We have
seen partial key recovery attacks against MD5 already and while
those do not allow an attacker to recover the full master password yet
(especially not with HMAC-MD5), I would not recommend anyone use MD5
in anything at this point, especially if changing that algorithm later
is hard. Some hashers (like Password Hasher and Password Plus) use a a
single round of SHA-1 to derive a token from a password; WPA2
(standardized in 2004) uses 4096 iterations of HMAC-SHA1. A recent US
National Institute of Standards and Technology (NIST) report
also recommends "at least 10,000 iterations of the hash
function".
Conclusion
Forced to suggest a password hasher, I would probably point to LessPass
or Master Password, depending on the platform of the person asking. But,
for now, I have determined that the security drawbacks of password
hashers are not acceptable and I do not recommend them. It makes my
password management recommendation shorter anyway: "remember a few
carefully generated passwords and shove everything else in a password
manager".
[Many thanks to Daniel Kahn Gillmor for the thorough reviews provided
for the password articles.]
Note: this article first appeared in
the Linux Weekly News. Also, details of my research into
password hashers are available in the password hashers history article.