I use the PwdHash service (http://crypto.stanford.edu/PwdHash/) and plugins for pretty much all of my passwords. I believe this is safer because:

  • No service gets the same password as another, so if one account is comprised my other ones shouldn't be.
  • The hashed passwords should be more secure than unique passwords I can realistically remember myself.

However, I am concerned that I could be exposing myself to risk by having a master password that, if comprised, can be used to gain access to all my services via PwdHash.

If an attacker has the hash, and knows that it was generated with PwdHash and knows the domain that it was generated for, how feasible would it be for them to determine the original password from that?

3 Answers 3


Having unique passwords entered to every site IS safer than giving each site the same password, for exactly the independent-compromise reason you suggested.

If an attacker has the hash, and knows that it was generated with PwdHash and knows the domain that it was generated for, how feasible would it be for them to determine the original password from that?

Well, let's do some investigation and some math! PwdHash appears to be using effectively GoofyStuff(Base64(HMAC-MD5())), so we're at the usual MD5(MD5()) guessing game speeds. Per oclHashcat, "PC5 (8x AMD R9 290Xstock core clock)" can crack ~81 Billion MD5's per second, so ~40 billion tries as PwdHash per second, which gives us the more practical 1E17 (somewhat over 2^56) tries per 30 days.

I base the above on this snippet from a quick glance at the PwdHash page source:

    var hash = b64_hmac_md5(password, realm);

This is in the range of an exhaustive keyspace search of 62^9 to 62^10 in those 30 days, where 62 is the keyspace of upper case, lower case, and numbers (or upper case, lower case, and the symbols above numbers, whichever you like), and 9 or 10 is the length.

Thus, a fully random upper case, lower case, numeric password encoded with HMAC-MD5 will be found in less than about 30 days (unless you and the attacker are using different character sets (i.e. Cryllic vs. English)). You'll need something with a larger total keyspace than this for your master password, and that's if it's a truly random password!

You don't even want to think about what a rules based dictionary attack can come up with at this speed, if your password is not, in fact, fully random. My most comprehensive wordlist set is over 40GB of unique passwords; if we assume an average word length of 9 plus a LF separator, that's 4E9 words, meaning that if an attacker with that PC spent 30 days on your password, they'd be able to try roughly 2.5E7, i.e. 25 million different variations (rules) for each password.

Note that this wordlist is too slow and cumbersome to bother with... unless the target can be attacked at insane speeds, like a single HMAC-MD5 can.

If you do use PwdHash with a master password, have a really, really good one - 15 character or better, cryptographically random, with a large character set (upper, lower, number, symbols above numbers, symbols not above numbers).

Other considerations

You should think about how you're going to change your master password after it leaks; perhaps you're up late and are trying to hurry and you type the master password into a web site directly instead of into PwdHash, just by habit, caffeine deprivation, hurry, and carelessness. Now you need to change it!

Personally, I like offline password storage like KeePass, but I'd much rather use even basic OpenSSL than PwdHash - AS PATHETICALLY INSUFFICIENT AS IT IS, I'll put HMAC-SHA-512 up against HMAC-MD5 any day of the week.

 echo example.com2014 | openssl dgst -sha512 -hmac MyPassword -binary | openssl enc -base64

As always, you're better off using something truly random and storing it, or, if you insist on a deterministic generation routine, something really, really slow - particularly since this is just for you, so PBKDF2/BCrypt/Scrypt with enough iterations/work factor that takes even a second or two or five on your machine would be just fine, and would slow down an attacker to a crawl.

Shameless plug: I'm working on collecting a variety of PBKDF2 (and hopefully later BCrypt and Scrypt) code examples at my Anti-weakpasswords github page, some of which compile so you can run them at the command line of Windows or Linux, and use them exactly the way you're using PwdHash now, but with a higher iteration count than almost any website could use, if you're willing to wait a couple seconds. As of today, there's only a Python version that Mitsuhiko wrote and Warner fixed for high iteration counts, not yet updated with better hashes, but that'll improve.

  • Amazing, wish I could upvote! Your Python script sounds perfect for my situation. Even the openssl command looks quite ideal for my situation.
    – MHG
    Feb 27, 2014 at 4:48
  • One issue though is that the majority of services put a limit on the number of characters that a password can contain. Some even limit what characters are acceptable. The PwdHash algorithm mitigates these problems by keeping the hashes to a shorter length and apparently keeping within the 'character set' (letters / numbers / punctuation / etc) that the original password used. I would imagine this reduces the security?
    – MHG
    Feb 27, 2014 at 4:51
  • Not my Python script - Mitsuhiko's with a patch from Warner :). Just choose the first 15 or so characters from whatever you get; you don't have to have the code shorten it for you - and it encouraging a short master password is nearly criminal! I've got C code that compiles under Linux (gcc + OpenSSL) and Windows (MinGW + OpenSSL) that'll go in soon, and other hopefully to come. WARNING: any local admin using Task Manager can see your command line arguments in modern Windows! Not even counting command line saving, clipboard copying, etc. Use on trusted machines only. Feb 27, 2014 at 4:52

There is a new research paper from December 2016, by David Llewellyn-Jones and Graham Rymer from the University of Cambridge on this topic:

Citation from the paper:

Abstract [...] We demonstrate how the hashcat password recovery tool can be extended to allow passwords generated using PwdHash to be identified and recovered, revealing the user’s master password. A leak from a single website can therefore compromise a user’s account on other sites where PwdHash was used. [...].

Conclusion: The main takeaway we want to emphasise from this work is that PwdHash is only as secure as the master password it’s used with. [...] Moreover, our results suggest that the message hasn’t been absorbed by PwdHash users, many of whom are using weak master passwords. Although the generated site-specific passwords appear strong, they are in fact no stronger than the original master password.

(emphasises mine)


This depends on the strength of your password. Using Anti-weakpasswords data above, a password of 15 random characters has 62^15 = 768909704948766668552634368 possible passwords. At 40 billion tries per second, this is 768909704948766668552634368 / 40000000000 = 19222742623719166 seconds = 609549169 years = 6E8 years. This is basically unbreakable using brute force.

Also, the number of characters in the password is more important than the password alphabet size, since the password length is the exponent in the formula and the alphabet (72) is the base. So, just using upper/lowercase characters (52 chars) gives 52^15 = 43569598 years = 4E7 years.

I use a device that provides me with 15 character random password and I use PwdHash. I agree with you, this is better than having a huge database of passwords. As long as you have a strong 15 character random password, you should be OK.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .