Hacker News Reader

Comment by tomjen3 | Hacker News Reader

What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords.

That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly better too.

View on HN

Reuse is a problem, but weak passwords are the biggest problem. If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended.

Generating server-side passwords is horrible as well since you're counting on the user to write it down and/or let the browser's password manager save it. What if the user wants to log in with a different machine/browser?

I think the best solution is to, first, forbid passwords under 10 characters. 8 is still relatively secure, but not really, 10 at least gives you a fighting chance. Second, run your own dictionary attack (you can load /usr/share/dict/words into a hashtable and check for membership in sub-second times..in fact, here:

    import sys
    f = open('/usr/share/dict/words')
    words = {}
    for line in f:
      words[line.replace('\n','')] = None
    
    if sys.argv[1] in words:
      print 'You fail'

) and alert the user if their password sucks and to pick a new one. (You might want to check for membership of their password with an 's' or a '1' or something added on as well.) You might also want to do some sort of complexity analysis as well that requires e.g. at least one uppercase, one lowercase, one number.

The infrastructure problem is places like Banks saying "Enter a password between 6 and 12 characters and only use alphanumeric characters!"

" If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended."

That unfortunately puts a lot of confidence in the security of the sites that you give your password to. Your super safe password is not that safe if a site stores it as plaintext or MD5 and it gets hacked.

Otherwise I agree with your comment.

A middle ground would be to generate password suggestions, but give the user the option to change his/her own password.

I used a method a few years ago to generate passwords for users on an intranet. They were free to replace them, but a poll showed that most users went with the suggested password. I focused on generating passwords that users could pronounce (and therefore remember), like gekava86, lofesu75, 23wopeni, etc.

At the time, I didn't use BCrypt so they were a bit weak (though certainly stronger than whatever the users' regular password was). If you use BCrypt, you don't have to worry as much about the password being "strong", the focus comes back to it being unique.

Eight characters for a password seems plenty long to me, if you're truly using a random password. You have [A-Za-z] = 52 chars, [0-9] = 10, [!@#$%^&()_-+=;':",.<>/?\|[]{}] = 30, for a total of 92 possibilities. Then you have an 8 character password. Even if the attacker knows you're using 8 characters, you've got ((92^8)0.3)/60/60/60/24/365/100 = 271 centuries if it takes 0.01 seconds a try. And we're really talking over 8 thousand centuries if we're having bcrypt take 0.3 seconds.

So the problem is that passwords tend not to be random. This greatly decreases the problem-space. But b/scrypt solves the problem of length, within reason.

I fully agree, but I'd focus more on the length than on the character set. It is not a problem if the password contains only alphanum characters, as long as those are random.

For instance, a plain alphanum password of length 9 is stronger than a password of length 8 that allows for special characters. (because 62^9 > 94^8)

In other words, adding one character to your password is as good as choosing from a bigger character set.

Okay, beginning at length 10, you'd need to add two characters, but that's really all you need to do up to length 20. (which is an insane length for a random password anyway)

C^x grows a lot faster than x^C, except for specific x's and C's you're almost always much better off adding to the length. And 20's nuttin'. At the risk of publishing more hastily written code for critiquing, here's a shell script password generator I use sometimes. https://gist.github.com/1058565

Yet with just [A-Za-z] and 10 random chars you're at 52^10 ~ 1E17 while your wider choice set gives 92^8 ~ 1E15, so ten random alpha chars is really better than ten alpha+number+punctuation. Suddenly it takes a paltry 229 thousand centuries (or 22 million years) with bcrypt at 0.3s.

Using punctuation does not make a password "more random", it only makes the random choice set slightly larger. Bumping the length is much more significant than bumping the set as it's exponential.

The debate is whether it's easier for a user to both pick and remember a "random-enough" - i.e not easily bruteforce-able, regardless of hashing technology - [A-Za-z]{10} password or a [A-Za-z0-9!@#$%^&()_-+=;':",.<>/?\|[\]{}]{8} password.

For the record, Google's 2-factor auth generated app-specific passwords are [a-z]{16}, which gives 1E22, or 230 billion years with bcrypt at 0.3s.

With $10k of GPUs, you can compute an MD5 hash for every 8-character ASCII printable password (yes, all 95^8 of them) in under a day.

This is why MD5 is not a good password-based key derivation function. :-)

That's a bit too simple - it won't catch password1 or iloveyou, both of which will definitely be tried by any decent cracker. Try http://www.openwall.com/passwdqc/, by Solar Designer (who has, among many other things, written the John the Ripper password cracker.)

You can also initialize the words in more pythonic way:

  with open('/usr/share/dict/words') as wordlist:
      words = set(line[:-1] for line in wordlist)

Or, for one time check you can stop reading on match:

  import sys
  lookup = '%s\n' % sys.argv[1]
  with open('/usr/share/dict/words') as wordlist:
      [ sys.stdout.write('Dictionary password: %s' % lookup) or sys.exit(1) for line in wordlist if line == lookup ]

As for the objective, this checks only exact dictionary matches. In real world, you'd use cracklib to check any dictionary based or weak passwords rather than reinvent the wheel. See http://gdub.wordpress.com/2006/08/26/using-cracklib-to-requi...

While I agree that the first code is pythonic and nice, the second code is quite the opposite of that. Why forcing imperative code into a list comprehension? It is a lot easier to read as nested loop, as it doesn't build a dummy list with some strange "or" operation:

  import sys
  lookup = '%s\n' % sys.argv[1]
  with open('/usr/share/dict/words') as wordlist:
      for line in wordlist:
          if line == lookup:
              sys.stdout.write('Dictionary password: %s' % lookup)
              sys.exit(1)

better to pickle a frozenset and use that.

  import pickle

  # initialize:
  wordset = frozenset(line.lower().rstrip() for line in open('/usr/share/dict/words'))
  pickle.dump(wordset, open('/tmp/wordset.pkl', 'wb', -1))

  # when you want to use it:
  wordset = pickle.load(open('/tmp/wordset.pkl', 'rb'))

  'bear' in wordset # == True

Thanks for the frozenset. Yet pickle makes the file 2 times bigger and 20 times slower to parse on my machine:

  >python wordlist.py -w wordlist -p wordlist.pkl
  >python wordlist.py -T wordlist wordlist.pkl 10 3
  2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)]
  words(wordfile): 142.50 best msec/loop
  words_slower(wordfile): 161.00 best msec/loop
  words_normalized(wordfile): 295.84 best msec/loop
  words_pickled(pickled): 2943.66 best msec/loop

The winner is:

  with open(wordfile) as wordlist:
      return frozenset(wordlist.read().split('\n'))

Source: https://gist.github.com/1059725

Wordlist: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/dict/web2?re...

Do you have different results?

right, the space saving harmed readability indeed, thanks

Another option is to test password complexity in javascript on client (ála Google and others), which provides immediate feedback to the user. This is prone to a dictionary attack only if the user uses well known character replacements like 'p@$sw0rd', which pass these tests undetected.

https://github.com/search?q=password+strength https://sun.athnic.net/password-test.html http://www.geekwisdom.com/dyn/passwdmeter http://cafewebmaster.com/check-password-safety-javascript-wh...

I personally hate it when sites do this. That's probably the best way to make sure I don't come back, as I'm not likely to remember the generated password. Worse, how do you give them the password? Email?

Also you have to trust the website: They shouldn't know your password, but if they just gave it to you then how do you know they're not keeping a copy themselves somewhere?

Can you stop a website that wants to save your password?

There are a lot of misconceptions on what makes a "secure" password—fluffy is puffy takes longer to crack than J4fS<2.

http://www.baekdal.com/tips/password-security-usability

"fluffy is puffy takes longer to crack than J4fS<2."

Assuming the attacker brute-forces all 3 word combinations, maybe. But "fluffy is puffy" is a valid English sentence and language is a rather poor source of entropy.

The problem with that approach is that people are very bad at remembering random strings of text, so they're likely to write this down or copy it somewhere on their computer.

Depending on the attack scenarios, that may not actually be more risky than allowing users to choose their own password..

I'd say that the best compromise of these approaches would be to encourage the use of password safe programs which at least store the password list in an encrypted format on local machines (of course this still relies on the user choosing a strong password for the password safe..)

Reply on news.ycombinator.com