6 ms·

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 everywhe

by Jach 15y ago

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!"

Fjolle 15y ago
" 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.
tjogin 15y ago
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.
ihodes 15y ago
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.
- vog 15y ago
  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)
  - Jach 15y ago
    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 https://gist.github.com/1058565
- lloeki 15y ago
  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.
JoachimSchipper 15y ago
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/ http://www.openwall.com/passwdqc/, by Solar Designer (who has, among many other things, written the John the Ripper password cracker.)
iki23 15y ago
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-require-stronger-passwords/ http://gdub.wordpress.com/2006/08/26/using-cracklib-to-requi...
- vog 15y ago
  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)
  - nerfhammer 15y ago
    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
    - iki23 15y ago
      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 https://gist.github.com/1059725 Wordlist: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/dict/web2?rev=1.14;content-type=text/plain http://www.freebsd.org/cgi/cvsweb.cgi/src/share/dict/web2?re... Do you have different results?
iki23 15y ago
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://github.com/search?q=password+strength https://sun.athnic.net/password-test.html https://sun.athnic.net/password-test.html http://www.geekwisdom.com/dyn/passwdmeter http://www.geekwisdom.com/dyn/passwdmeter http://cafewebmaster.com/check-password-safety-javascript-while-typing http://cafewebmaster.com/check-password-safety-javascript-wh...

by Jach 15y ago

Fjolle 15y ago

" 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.

tjogin 15y ago

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.

ihodes 15y ago

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.

vog 15y ago
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)
- Jach 15y ago
  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 https://gist.github.com/1058565
lloeki 15y ago
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.

JoachimSchipper 15y ago

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/ http://www.openwall.com/passwdqc/, by Solar Designer (who has, among many other things, written the John the Ripper password cracker.)

iki23 15y ago

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-require-stronger-passwords/ http://gdub.wordpress.com/2006/08/26/using-cracklib-to-requi...

vog 15y ago
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)
- nerfhammer 15y ago
  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
  - iki23 15y ago
    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 https://gist.github.com/1059725 Wordlist: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/dict/web2?rev=1.14;content-type=text/plain http://www.freebsd.org/cgi/cvsweb.cgi/src/share/dict/web2?re... Do you have different results?

iki23 15y ago

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://github.com/search?q=password+strength https://sun.athnic.net/password-test.html https://sun.athnic.net/password-test.html http://www.geekwisdom.com/dyn/passwdmeter http://www.geekwisdom.com/dyn/passwdmeter http://cafewebmaster.com/check-password-safety-javascript-while-typing http://cafewebmaster.com/check-password-safety-javascript-wh...