Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How To Safely Store A Password

codahale.com

Post reply on HN
Print view View original

191–200 of 215 posts

Re: How To Safely Store A Password

#191

Post by falcolas »

dpark wrote: post #189
falcolas wrote: post #185

Earlier quoted context omitted.

In the court of public image, simply loosing the data in the first place will cost you business, now matter how secure that data may be. The trust to secure your data will be lost, regardless of whether you used bcrypt or sha or plaintext. If you consider the loss of business to be pretty much constant in the event of a loss of control of the customer's data, what is the value of extra server(s) (plus the cost of mai…

For sure there's going to be loss of confidence either way. You're probably going to have a bigger loss if the security experts are pointing out that you couldn't even get password storage right, though. Obviously they It's up to you whether you care enough about your customers to try to get security right. You gave a reasonable argument for why using bcrypt instead of md5 makes little financial sense. However, that…

Plaintest vs. hash, or salted hash vs. salted hash do not incur the same performance penalty.

And while I may feel morally obligated to provide great security, the people I report to would not be as impressed with that in a cost-benefit analysis.

tl;dr It's a great idea, but a tough sell, particularly at scale.

Re: How To Safely Store A Password

#192

Post by iki23 »

vog wrote: post #78
iki23 wrote: post #75

Earlier quoted context omitted.

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 objecti…

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('Dict…

right, the space saving harmed readability indeed, thanks

Re: How To Safely Store A Password

#193

Post by dpark »

falcolas wrote: post #191
dpark wrote: post #189

Earlier quoted context omitted.

For sure there's going to be loss of confidence either way. You're probably going to have a bigger loss if the security experts are pointing out that you couldn't even get password storage right, though. Obviously they It's up to you whether you care enough about your customers to try to get security right. You gave a reasonable argument for why using bcrypt instead of md5 makes little financial sense. However, that…

Plaintest vs. hash, or salted hash vs. salted hash do not incur the same performance penalty. And while I may feel morally obligated to provide great security, the people I report to would not be as impressed with that in a cost-benefit analysis. tl;dr It's a great idea, but a tough sell, particularly at scale.

My hashed/unhashed comparison was not a performance statement, but a trust statement. If a breach will lose the same amount of confidence regardless of password storage, why bother with even hashing?

I can't imagine how "good security - scalable enough for Twitter" can be a hard sell. Your customers certainly won't by sympathetic if they learn that you willfully chose weaker security to save a buck.

Re: How To Safely Store A Password

#194

Post by yuhong »

16s wrote: post #112

It's good to raise awareness of this issue. When more devs began using bcrypt or scrypt, offline password cracking will be much, much more difficult. The only reason GPUs are cited as testing 600 million hashes a second is that the underlying hashes came from a Microsoft Windows Active Directory where they were simply MD4 encoded. That speed is not possible with bcrypt. Devs need to understand this. Edit: Yes, that's…

And note if you already have this hash you can use it to login directly anyway as most Windows network protocols take this hash directly. The real important thing IMO is NTLM challenge/responses based on the hash, which unfortunately is not much better. In case of NTLMv1/MS-CHAP it is three 56-bit DES operations on separate parts of the 128-bit hash (the third being only 2^16 so it is easy to precompute, as shown by asleap). NTLMv2's HMAC-MD5 is fast too.

Re: How To Safely Store A Password

#195

Post by barefoot »

nlco wrote: post #148
barefoot wrote: post #138

Earlier quoted context omitted.

Hashing passwords on the client indicates that the salt is available to the client. In the event of a database compromise it's guaranteed then that the attacker will have the salt and be able to crack your passwords. If the salt is stored on the server, in a login.php script for example, and there is (just) a database compromise then an attacker will be at a disadvantage because they will need to figure out the salt…

Salts are suppose to be considered public. For the most part, they are defenses against rainbow tables and to make an attacker have crack each password individually.

Agreed, but an important part of the article was that even public salted md5 passwords are ineffective.

Re: How To Safely Store A Password

#196

Post by pavpanchekha »

zepolen wrote: post #183
Someone wrote: post #130

Earlier quoted context omitted.

If the client sends hash(password) to the server, hash(password), for all intents and purposes, _is_ the password. After all, an attacker does not need to recover the password from the hash, all he has to do is capture the hash and replay it.

I'm no crypto expert but wouldn't using a nonce allow this approach to work?

How would you check the nonce? All your server gets is a black box hash.

Re: How To Safely Store A Password

#197

Post by iki23 »

nerfhammer wrote: post #156
vog wrote: post #78

Earlier quoted context omitted.

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('Dict…

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?

Re: How To Safely Store A Password

#198

Post by iki23 »

Jach wrote: post #44
tomjen3 wrote: post #41

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…

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 machi…

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

Re: How To Safely Store A Password

#199

Post by pjscott »

Xk wrote: post #21
firsttimeposter wrote: post #11

People keep posting this here. But I think http://www.tarsnap.com/scrypt.html should probably be considered the best way to do this today. Google is even using it in ChromeOS.

It is true that scrypt is better than bcrypt, but the transition from salt+SHA-1 to bcrypt is significatnly better than from bcrypt to scrypt, and scrypt doesn't have nearly as nice of an interface as bcrypt does.

The easy interface and wide availability of language bindings to bcrypt is a big deal. The easier it is to use, the more likely people are to use it, and the less likely they are to mess it up. Scrypt isn't quite there yet, and bcrypt is still very good.
Post reply on HN