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

211–219 of 219 posts

Re: How To Safely Store A Password

#211

Post by StavrosK »

Cushman wrote: post #209
StavrosK wrote: post #190

Earlier quoted context omitted.

> As it stands today, anyone using one of those is instantly compromised the moment the hash file is accessed. How? If hashing one password takes one second, and you have a dump of a thousand users, it will take you a million seconds to try just 1,000 common passwords on that list. Are you thinking of unsalted hashes, perhaps?

As noted in the OP, it takes far, far less than one second to hash one password using standard algorithms.

It seemed to me like you were talking about bcrypt, weren't you?

Re: How To Safely Store A Password

#212

Post by [deleted] »

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.

[deleted]

Re: How To Safely Store A Password

#213

Post by seunosewa »

gxti wrote: post #168
tocomment wrote: post #150

Some everyone is saying how easy it is to crack md5. Say I have an md5 hash and I know it was created from a 1000 byte string. How long would it take to enumerate all 1000 byte strings that could create that hash?

Actually you can (almost surely) stop cracking at 16 bytes, because that's how long MD5 digests are and any more bits than that are going to give you hashes you've already seen. You won't get back the original string but you don't need the original string.

Actually, you have to go a bit beyond 16 bytes to be sure.

Re: How To Safely Store A Password

#214

Post by jasonwatkinspdx »

alanh wrote: post #162
jasonwatkinspdx wrote: post #151

Earlier quoted context omitted.

This exposes information about the password: namely it's estimated entropy. The bet you're making is that the increased work factor overshadows any advantage an attacker may gain knowing that information. How could someone use this? Well, I could decide to only target the rows with a low work factor. Since your entropy estimate is high for these rows, I can know that it's more likely they'll be 8 characters or longer…

If I’m remembering my discrete math correctly, your claim isn’t correct: > … Let's assume 2 choices of work factor. Also let's assume strong passwords of length 8 have 96^8 ~= 53 bits of entropy and eak passwords of length 8 or less have 27^8 ~= 38 bits of entropy. > You just let me cut the search space for strong passwords of length 8 to to ~15 bits… You can’t subtract bits of entropy like that. Here’s something I h…

Thanks for the correction!

Re: How To Safely Store A Password

#215

Post by jasonwatkinspdx »

a_m0d wrote: post #166
jasonwatkinspdx wrote: post #151

Earlier quoted context omitted.

This exposes information about the password: namely it's estimated entropy. The bet you're making is that the increased work factor overshadows any advantage an attacker may gain knowing that information. How could someone use this? Well, I could decide to only target the rows with a low work factor. Since your entropy estimate is high for these rows, I can know that it's more likely they'll be 8 characters or longer…

If I understand the grandparent correctly, there would be no way to determine which rows have a higher work factor. The work factor would be determined when the password is given, based on the password entropy - the correct password will always have the same entropy, therefore the same work factor. If the work factor is calculated on the wrong password (typo, etc.) it will not generate the correct hash anyway. Theref…

Ah, yes, I'd missed that. Since you have the password at login time, you don't need to store the work factor. There are some practical things about making sure you can version the entropy estimate code without breaking existing logins, but it's certainly doable.

Re: How To Safely Store A Password

#216

Post by Cushman »

StavrosK wrote: post #211
Cushman wrote: post #209

Earlier quoted context omitted.

As noted in the OP, it takes far, far less than one second to hash one password using standard algorithms.

It seemed to me like you were talking about bcrypt, weren't you?

Well, the argument was that user-imperceptible hash times should be sufficient for all passwords. I was trying to make the case that even the class of extremely weak passwords can be protected with perceptible hash times.

So really I think you were demonstrating my point :)

Re: How To Safely Store A Password

#217

Post by nkurz »

StavrosK wrote: post #192
nkurz wrote: post #84

Earlier quoted context omitted.

I can probably top you: some many years ago, I discovered that Network Solutions (the original domain name provider) was using the first two characters of the password as the salt for their user accounts, presumably so that the salt could also be secret. Of course, this had the side-effect of making the first two characters of the password visible in plain text if you looked at the hashes. I reported this as a bug an…

Using two-character salts might be as big of a wtf here.

Perhaps in retrospect, but this was standard for the Unix crypt() function and passwd files of the time: http://linux.die.net/man/3/crypt The dangers of rainbow table attacks weren't well considered at the time.

The real error was misreading the man page and using the first two characters as the salt, which is then published as the first two characters of the hash. It's sort of an easy error to make, because to decrypt, you do use the first two characters of the hash. Understandable for a beginner working on a school project, but pretty ludicrous for a large company holding control over most of the domains on the internet at the time.

Re: How To Safely Store A Password

#218

Post by andreyf »

gcr wrote: post #143
andreyf wrote: post #133

Earlier quoted context omitted.

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

Elaborate. Obviously its security depends on the hashing scheme (if it's CRC32, you could find a collision pretty easily), but educate us -- is that all you meant?

That's all I meant. 8 type-able characters is pretty easy to break if you have a couple of grand to invest in GPU's.

Re: How To Safely Store A Password

#219

Post by stcredzero »

Cushman wrote: post #210
stcredzero wrote: post #199

Earlier quoted context omitted.

I think it would be enough to get hold of the 1,000,000 most common passwords and tell the user it's not allowed.

That still leaves you open to side-channel attacks, yes? It's easy for an attacker to find which passwords are prohibited, so by restricting them you remove them from the search space. But your users aren't going to start choosing fundamentally secure passwords, the attack just shifts to the next 1,000,000 common passwords.

Maybe it just shifts to the secure password you generate and suggest to them?
Post reply on HN