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

Storing Passwords Securely

throwingfire.com

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Storing Passwords Securely

#131

Post by masklinn »

ashconnor wrote: post #77
pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

No it's not a bad idea and essentially it's what BCrypt does. Think about it. If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords. However if there is a different salt for each password then this type of attack becomes more difficult as I have to essentially do the same amount of work for only a single pa…

> If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords.

That's not a rainbow table, a rainbow table is a list of precomputed hashes (which you'd just do once on a cluster you pay — of buy from a guy who did — and then store/stash)

But you're brute-forcing the whole table (you can look for matches after each computation) instead of having to individually brute-force each password. But you wouldn't keep the forced salted hashes around since there's no need for them once you've tested the leaked hashes.

Re: Storing Passwords Securely

#132

Post by Morg »

Author: 'There is no reason not to do this for your users.'

Yes there is. if every password auth costs you half a billion bucks, you're in trouble.

Seriously considering running a hashing routine for more than a second is absolutely unscalable and not smart - you're going to spend infinity computing resources making a super hash of doom for a not-very-important bad quality password like "superMonkey69".

Education is still the best answer, when everybody's password is correct horse battery staple, we shall have peace.

Re: Storing Passwords Securely

#133

Post by ashconnor »

masklinn wrote: post #131
ashconnor wrote: post #77

Earlier quoted context omitted.

No it's not a bad idea and essentially it's what BCrypt does. Think about it. If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords. However if there is a different salt for each password then this type of attack becomes more difficult as I have to essentially do the same amount of work for only a single pa…

> If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords. That's not a rainbow table, a rainbow table is a list of precomputed hashes (which you'd just do once on a cluster you pay — of buy from a guy who did — and then store/stash) But you're brute-forcing the whole table (you can look for matches after eac…

Yeah I should have stuck that in quotes. I was trying to keep the explanation as simple as possible.

You are right of course there is no need to keep hashes about once they have been compared against the db.

Re: Storing Passwords Securely

#134

Post by ZoFreX »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

This might be useful for you or anyone else with the same question: http://stackoverflow.com/questions/2583203/salt-passwords-an...

Re: Storing Passwords Securely

#135

Post by exDM69 »

yichi wrote: post #19
sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

There are no known good implementation of scrypt in php ( http://stackoverflow.com/questions/10149554/are-there-any-ph... ) So I don't know how "production ready" that is considering php is the most popular platform for the web as much as I hate the language.

It's not a very good idea to implement cryptography in a high level language such as PHP. Using a high level language opens a whole new world of pain when it comes to side channel attacks. Timing attacks, cache timing attacks and branch predictor attacks are much easier to protect yourself against if you write your crypto algorithms in C or, preferably, Assembly.

Re: Storing Passwords Securely

#136

Post by jimktrains2 »

exDM69 wrote: post #135
yichi wrote: post #19

Earlier quoted context omitted.

There are no known good implementation of scrypt in php ( http://stackoverflow.com/questions/10149554/are-there-any-ph... ) So I don't know how "production ready" that is considering php is the most popular platform for the web as much as I hate the language.

It's not a very good idea to implement cryptography in a high level language such as PHP. Using a high level language opens a whole new world of pain when it comes to side channel attacks. Timing attacks, cache timing attacks and branch predictor attacks are much easier to protect yourself against if you write your crypto algorithms in C or, preferably, Assembly.

C module?

Re: Storing Passwords Securely

#137

Post by exDM69 »

jimktrains2 wrote: post #136
exDM69 wrote: post #135

Earlier quoted context omitted.

It's not a very good idea to implement cryptography in a high level language such as PHP. Using a high level language opens a whole new world of pain when it comes to side channel attacks. Timing attacks, cache timing attacks and branch predictor attacks are much easier to protect yourself against if you write your crypto algorithms in C or, preferably, Assembly.

C module?

Writing your crypto with C and then calling it from another language such as PHP or Python is fine.

Re: Storing Passwords Securely

#138

Post by kmfrk »

kmfrk wrote: post #66
jharding wrote: post #11

If you're storing passwords as MD5/SHA hashes, how difficult is it be to switch over to bcrypt? I've never had to do this, but I would imagine it would be somewhat trivial. With all of the password leaks that have happened over the past few years, I'd imagine a good amount of developers are aware that storing passwords as MD5/SHA hashes is somewhat risky, so I can't understand why big websites (LinkedIn) are still do…

In Django, as I recall, you just check for a hashing indicator that's prefixed to the hashed password, and do something like this on a user's log-in: if hashed_password.startswith("sha$"): hashed_password = bcrypt(hashed_password) (or `... = "bc$" + bcrypt(hashed_password)`. However it's done.) Here is the relevant code for django-bcrypt: https://github.com/dwaiter/django-bcrypt/blob/master/django_... . In your case,…

On a quick revision, the first code should read

   hashed_password = bcrypt(entered_password)
Not `bcrypt(hashed_password)`.

Re: Storing Passwords Securely

#139

Post by tptacek »

tveita wrote: post #116
tptacek wrote: post #100

Earlier quoted context omitted.

The "timing leak" here does not uniquely identify any word in the dictionary; the attacker is on the opposite side of the problem. This attack is implausible.

I'll make one more attempt. I don't think I can explain it any clearer than this: http://pastebin.com/MYT9kpgZ Here I model the server as a simple function that takes a password, hashes it, and compares it to a known digest with an '==' substitute. The function returns true or false, but also leaks information about how long the match was, through a simulated timing leak. This lets me identify the dictionary word tha…

No, I understand the attack you're proposing. I just don't think it works, or, for that matter, buys you much of anything.

Some things a reader of this thread would want to know, to make sense of it:

* C memcmp (which is what Python uses) is below the known measurement floor for remote timing.

* With (many) repeated trials and statistical filtering, the floor is (IIRC, but just Google [crosby wallach timing]) hundreds of nanoseconds on a LAN, tens of microseconds on a WAN.

* The difference between 1 and 2 bytes of matched SHA1 hash is certainly not a millisecond.

* Even if it was a millisecond, which it isn't, you'd come to that conclusion only after many repeated trials.

* To make this attack appear worthwhile, you introduced an artificial rate limit of 1 attempt per second, but obviously ignored that limit when trying to measure the (very noisy) timing of each hash byte.

* Obviously, you can't time a randomized hash, because you don't know enough to generate proposed password hashes to match against.

* The 4-byte shared prefix you're looking for is probably not present in the set of all valid passwords; or, put differently, you'd have better luck just guessing likely passwords through repeated trials than you would making repeated trials to find a next prefix byte.

I'm not disputing that there's information of some sort "leaked" in a password hash comparison; I'm just disputing that it's valuable in any way to a real world attacker.

A more effective way to try to launch this attack would be to try to dump the set of all users known to the system. This attack, far more straightforward than the one you proposed, also doesn't work because of measurement difficulties, but it at least has value in theory, doesn't depend on arbitrary shifting obstacles for the attacker, and nobody in the history of web app development has ever tried to stop it.

Re: Storing Passwords Securely

#140

Post by mcherm »

wtracy wrote: post #93
stickfigure wrote: post #75

Earlier quoted context omitted.

Furthermore, it's important that the salt be unique per password . If you had a single common salt in your code, then two users with the same password would produce the same hash.

Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples! Thanks for bringing this up--the concept of salt makes a lot more sense to me now.

Using the same salt for every password in the database protects against an attacker using a pre-computed dictionary ("rainbow tables" are something like this) to attack your stored hash values. Using (and storing) a separate salt for each password protects against that and ALSO protects against the attacker building a dictionary of common passwords with a certain salt and then using that dictionary to crack ALL the passwords in the database at once.

So one-salt-per-user is clearly better, but one-salt-for-all is still better than no-salt-at-all.

Post reply on HN