15

There are two password generators on ss64.com:

How they work

I made standalone versions of them, plus copy of the original HTML/Javascript versions, if you want to study them, but here is how they work:

This section explains how the passwords generator work, such that it is possible to roll out a standalone version that does not depend on relying on a third party web site.

  • You have a master password, let's say foo
  • You generate a password for a specific site or service, let's say stackexchange

  • You compute the SHA1 sum (standard version) or SHA256 sum (strong version) of the string foo:stackexchange.

    $ echo -n "foo:stackexchange" | sha1sum      #standard version
b99341502484edbc43ec35a5f94be8e5de7ca53a *-

$ echo -n "foo:stackexchange" | sha256sum    #strong version
c6ac66fdb639821bcc322f186fb1214d241f35ba2a91cb660daf0a284ac19a47 *-

  • You apply Base64-transformation on the sequence of bytes of which the hexadecimal representation is the previously generated checksum:

    $ printf "\xb9\x93\x41\x50\x24\x84\xed\xbc\x43\xec\x35\xa5\xf9\x4b\xe8\xe5\xde\x7c\xa5\x3a" | base64
uZNBUCSE7bxD7DWl+Uvo5d58pTo=

$ printf "\xc6\xac\x66\xfd\xb6\x39\x82\x1b\xcc\x32\x2f\x18\x6f\xb1\x21\x4d\x24\x1f\x35\xba\x2a\x91\xcb\x66\x0d\xaf\x0a\x28\x4a\xc1\x9a\x47" | base64
xqxm/bY5ghvMMi8Yb7EhTSQfNboqkctmDa8KKErBmkc=

  • (strong version) you replace + with E and / with a, and take first 20 characters

  • (standard version) you take first 8 characters and then add 1a at the end of the password to ensure there is at least one digit and one letter

Therefore, with master password foo, and for specific site stackexchange, the standard generated password is uZNBACSE1a and the strong generated password is xqxmabY5ghvMMi8Yb7Eh.

Now the questions

  • Is the strong version really stronger than the standard version? Would it still be stronger if the standard version also used SHA256?
  • provided that I choose a good master key (not foo, rather more than 10 random characters), am I rather safe with these generated passwords?
  • What can be other drawbacks of this approach towards creating passwords?
Benoit
  • 493
  • 1
  • 5
  • 11
  • 1) Entering your password on an untrusted website is risky 2) Their hash-function is probably too fast. It's preferable to use an iterated scheme 3) Appending `1a` is plain silly. 4) Using the username as salt would be a good idea as well, to prevent multi-target attacks. – CodesInChaos Oct 24 '13 at 08:51
  • @CodesInChaos: to answer this: 1) that's why I tried to understand what the js code does – 2) could you expand on that in an answer? 3) yes it is, so is replacing +/ with Ea, but this is provided by the script in order to generate passwords that are compatible with password policies of most web sites. When you've 8 random characters among the base64 set, there are chances there is no single digit for example. But appending characters does not make passwords less secure. 4) Could you expand on that in an answer? Thanks. – Benoit Oct 24 '13 at 09:55
  • 1
    Those passwords will fail on those sites that require at least one symbol. The Base64 will only represent a-z, A-Z and numbers, since the + and / will be replaced by E and a. – woliveirajr Oct 24 '13 at 11:44

2 Answers2

14

There are two levels of strength here:

  • Whether the provided password will be, by itself, strong (against brute force).
  • Whether someone learning one of your passwords on one site will gain leverage for guessing your passwords on other sites (e.g. by guessing the "master password").

The "standard" version produces passwords with 48 bits of entropy: Base64 encoding is 6 bits per character, and the generator uses 8 characters (the "1a" suffix is fixed, so it does not change security at all). 48 bits of entropy are not bad, especially in the context of online attacks, where the attacker must talk to the server for each try. If the server gets hacked (database dump through SQL injection) and the server did not use proper password hashing, the an industrious and motivated attacker may break through it; in that sense the "strong" version is a bit stronger than the standard version. However, in that specific case, I'd say that the weakness is in the server, not the password (not using proper password hashing is the bad point here).

Note that switching from SHA-1 to SHA-256 does not improve security. It is not bad, but it offers a practical gain only insofar as SHA-1 does not provide good preimage resistance, and, right now, SHA-1 is still as good as new in that respect.

For the second level (escalating from site password to master password), both versions are weak because they are way too fast. Given a site-specific password, enumerating potential master passwords can be done at a rate of a few billions per second (with a couple good GPU). Moreover, since the transformation is not salted except by the site name, if several people use the same method for their passwords on the same site then their master passwords can be brute-forced in parallel. The "strong" version is not much stronger at that level than the "standard" version, except for the fact that SHA-256 is about twice slower than SHA-1, thus doubling the attacker's cost.

The approach also suffers from a few usability issues:

  • If the server requests that a user changes his password, the user cannot comply, because the method produces one password for a given master password and site name.

  • If the site name changes, then the password generation breaks.

  • Some servers have special requirements which are not necessarily fulfilled by the generated password (e.g. some servers mandate that passwords shall contain at least one punctuation sign -- a misguided requirement, but it happens).

  • Others have pointed out the problem of entering your master password on a page served by a third party Web site -- page whose contents may be changed without notice and without any visible warning. A stand-alone version avoids this problem, but if stand-alone applications are allowed, then this opens the possibility of using a better system.

Indeed, more flexible solutions (e.g. KeePass) use a storage system. There is one indirection: the master password is used to encrypt a bundle which contains the actual passwords. This allows for changing passwords and fulfilling other requirements.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 3
    +1 for the suggestion to use keepass instead of this scheme. – John Deters Oct 26 '13 at 19:08
  • Where do you see entropy in this scheme? To my reading, the only entropy comes from the master password and site-specific passwords. The rest is simply a transform which doesn't appear to add any actual value other than obscurity. – Stephen Touset Oct 26 '13 at 20:09
  • Assuming that the master password is of high enough entropy to defeat brute force, and that the hash function (SHA-1 or SHA-256) acts as a random oracle, then the site-specific passwords are "as if" they were randomly generated, from the point of view of the attacker. Talking of their individual "entropy" is thus scientifically justified (distinguishing them from random passwords involves breaking the hash function or recovering the master password). – Thomas Pornin Oct 26 '13 at 21:09
  • I think that's a pretty major assumption you've left unstated, there. That would require longer than an 8-character randomly generated alphanumeric password, which is I think well above the average. I'd suggest more clearly establishing that the approach creates passwords with a *maximum* of 48 bits of entropy. – Stephen Touset Oct 27 '13 at 04:39
  • 2
    Thank you for this answer. Some followup: 1/ I understand that this approach is not flexible. I suppose I could introduce salt in the site name by prefixing with `username@` and suffixing with `:2013Q1` for example if passwords expire every 90 days. Would that solve the problems you describe? 2/ My problem with keepass-like solutions is that I might lose the bundle (no storage is really safe) or forget to take it with me. Could you suggest an alternative system which does not require carrying a file? 3/ For website specific special requirements, you're 100% right. – Benoit Oct 29 '13 at 14:04
9

Some good points mentioned above, but I think it's worth running some numbers to show how the password length affects this.

A GPU cluster capable of 350 billion guesses/second
350000000000 *60 *60 = 1.26e+15 Guesses /hour
or 1.10376e+19 Guesses/year

An 8 character random password with 48 bits of entropy
2^48 = 2.8147498e+14 possible combinations
So the time to crack 8 character password:
2.8147498e+14 / 1.26e+15 = 0.223 Hours

A 10 character random password with 59 bits of entropy
2^59 = 5.7646075e+17 possible combinations
Time to crack 10 character password:
5.7646075e+17 / 1.26e+15 = 457.50 Hours

A 15 character random password with 89 bits of entropy
2^89 = 6.1897002e+26 possible combinations
Time to crack 15 character password:
6.1897002e+26 / 1.10376e+19 = 56078315.93 Years

A 20 character random password with 119 bits of entropy
2^119 = 6.64614e+35 possible combinations
Time to crack 20 character password:
6.64614e+35 / 1.10376e+19 = 6.0213633e+16 Years

So the key takeaway here is that both the generated password and the master password need to have sufficient password length/entropy to defend against an offline attack.

Edit: just to add, those are maximum times, the average will be half those values.

SS64
  • 91
  • 3