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

131–140 of 219 posts

Re: How To Safely Store A Password

#131

Post by e1ven »

tptacek wrote: post #63
jmillikin wrote: post #57

Earlier quoted context omitted.

No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. I know there's lots of ways to screw up security, but most of them derive from lazy people taking shortcuts. They run the httpd, database, and authentication all off the same server so a vu…

SHA1(salt || password) is an incompetent design that is debatably even easier to crack than the Gawker hashes. The insecurity of that construction is why we have PBKDF2. If the entire knowledge you have of cryptography comes from _Applied Cryptography_ --- wait; let me extend that: if you even feel the need to cite _Applied Cryptography_ --- you should be careful debating crypto constructions. You're not going to end…

I don't have a dog in this race either way, but I'm curious what you dislike about Schneier's book.

Re: How To Safely Store A Password

#132

Post by nitrogen »

dguido wrote: post #56
jmillikin wrote: post #42

Earlier quoted context omitted.

> That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. I don't understand why you'd add extra content to the password unless you keep it secret. The whole point of a salt/nonce is to prevent attackers from attacking the digest, right? You need some per-user data, to defend against rainbow tables, and some per-site data, to protect weak passwords. My f…

Basic version: The salt prevents an attacker from being able to pre-compute a mapping from password hash value. It's most effective when it changes per-password and it doesn't matter if it's public. http://en.wikipedia.org/wiki/Salt_(cryptography)

To make it even more obvious, it's to prevent this (I haven't done SQL in a long while so this may be broken):

  SELECT username FROM users WHERE password=HASH('secret');
I've seen systems where that statement will give a list of all usernames with the password "secret".

Re: How To Safely Store A Password

#133

Post by andreyf »

Cushman wrote: post #70
tptacek wrote: post #55

Earlier quoted context omitted.

You're overthinking both the security aspect of this and the performance aspect of it. User-imperceptible hash times are adequate to make most conceivable brute force attacks intractable.

That's true of passwords over a certain strength, for sure. And it always has been; "6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time. But as computing power increases, that minimum strength is being pushed out. bcrypt lets us hold the line by keeping pace with computing power— couldn't it also give us the ability to push back? How many users are using the…

"6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time.

False.

Re: How To Safely Store A Password

#134

Post by csytan »

tptacek wrote: post #72
miGlanz wrote: post #69

Earlier quoted context omitted.

Imagine this Python code (I'm using SHA1 iterated multiple times, basically PBKDF2): import hashlib hashed = password for i in range(50000): hashed = hashlib.sha1(salt + hashed) Provided we also store the number of iterations (along with the salt), and provided I didn't do anything stupid above, we could simply add more iterations after these 5 years and update hash and number of iterations field. Would it be a viabl…

Yes.

I rigged up a small test on my Macbook. Do you think 50,000 iterations would be enough for a general website (such as HN)?

    import timeit
    
    t = timeit.Timer(stmt="""\
    def test(pwd, n_iter):
        for i in range(n_iter):
            pwd = hashlib.sha1(pwd).hexdigest()
    test('hello', 50000)
    """, setup='import hashlib')

    print t.timeit(100) / 100
    
    >>> 0.126629960537

Re: How To Safely Store A Password

#135

Post by timtadh »

csytan wrote: post #124
brown9-2 wrote: post #96

Earlier quoted context omitted.

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

I can think of one reason: Lack of the available libraries on a particular platform.

This is why I mentioned it. It provides improved time guarantees for your users with out needing another library.

Re: How To Safely Store A Password

#136

Post by Xk »

tptacek wrote: post #129
codexon wrote: post #123

Earlier quoted context omitted.

If you have 10 people logging in per second, you put a 1 second delay on future requests which is certainly noticeable. Maybe the correct thing to do is to make the key derivation executed on the client side, but then this would erode the experience of mobile phone users.

There is no way to securely do this clientside. It's hard to imagine a situation in which login overhead is painful where scaling in general isn't already a huge concern; presumably, anything you do after login is going to be more painful than bcrypt.

I would imagine some kind of zero-knowledge proof would work here, but that would require more server interaction than just doing the hashes in the first place.

Re: How To Safely Store A Password

#137

Post by ErrantX »

Ixiaus wrote: post #120
Xk wrote: post #65

Earlier quoted context omitted.

What do you mean by "my salting algorithm is very strong"?

Instead of just concatenating a salt to the password string, I use a dispersion method. I first concat the salt to the beginning of the password and SHA512 that. I then have a globally configured list in my app (it's different for every app I produce) that defines at which index, in the hashed salt+password digest, chunks of the (same) salt are sliced and interspersed. Given the same list of indexes, I can then "find…

Poor mans solution here is to iterate your fast hash a number of times.

This is essentially what bcrypt does for you anyway (in a really crude sense).

Re: How To Safely Store A Password

#138

Post by paperclip »

csytan wrote: post #124
brown9-2 wrote: post #96

Earlier quoted context omitted.

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

I can think of one reason: Lack of the available libraries on a particular platform.

bcrypt is open source and ported to a range of operating systems. I cannot imagine getting it up and running on any system would be too difficult. It would probably be wiser to to spend the time to get bcrypt (or another standard scheme) working rather than coming up with some custom scheme which probably hasn't had the same level of thought put into it.

Re: How To Safely Store A Password

#139

Post by youngian »

tptacek wrote: post #59
bostonvaulter2 wrote: post #43

Earlier quoted context omitted.

I think the point is that you should use bcrypt and salt at the same time.

You don't need to do anything like that; bcrypt does all this stuff for you. Don't salt bcrypt.

I think people would be a lot less confused if you said this first. Say "Don't salt bcrypt, bcrypt salts for you" and you'll have to explain yourself less.

Re: How To Safely Store A Password

#140

Post by bigiain »

JonnieCache wrote: post #95
tptacek wrote: post #52

Earlier quoted context omitted.

If you lose code execution on your server to an attacker, you're done. 100% fucked. Everything in your environment needs to get stripped down and rebuilt from trusted sources. Do not be one of those people who rationalizes "oh, I just lost uid=4294967294". Gawker lost root. So will you.

And if you lose root, the disk must be reimaged. Rootkits are too advanced these days to ever make the assumption that you have removed them.

It's possible that sometime not too far in the future that advice might need to be upgraded to "If you lose root, unplug and destroy the hardware and install a completely new machine from trusted sources".

http://www.theregister.co.uk/2010/11/23/network_card_rootkit...

(Why yes, I _did_ have that problem weighing on my mind while I investigated several machines that had a weekends worth of exposure to the recent Exim remote root exploit...)

Post reply on HN