What work factor do you recommend to make it reasonably fast and still bruteforce-proof with the current HW?
How To Safely Store A Password
121–130 of 215 posts
Re: How To Safely Store A Password
#122Many developers need to read and understand this. It is far from mainstream knowledge... The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110 - No mention of bcrypt (though the posts mentions key stretching using SHA1) - "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm l…
What about Debian's reason for not using bcrypt, claiming the time it takes to hash is not a weak point in security of /etc/shadow?
http://groups.google.com/group/linux.debian.user/browse_thre...
Re: How To Safely Store A Password
#123Earlier quoted context omitted.
Several of the largest sites in the world have scaled bcrypt. There are longer answers as to why this is not a big deal, but if it helps to kill the red herring that bcrypt might not scale: Twitter uses it.
I'm really interested into the longer answer! I'm sold on bcrypt but like to hear scaling stories :)
One possible, slightly longer, answer would be that "login" is a relatively rare operation in the grand scheme of things.
Users (usually) need to login only once per session. And on sites that have the little "Remember me"-tickbox a session may very well last for days or even months.
Re: How To Safely Store A Password
#124Earlier quoted context omitted.
Timing attacks are not a problem if you're using it to hash passwords. Also, Javascript implementations don't use doubles for pure integer arithmetic.
If I can observe your (SSL-encrypted) login session, I can time how long the server takes to process your (presumably real) password. What makes you think password hashes don't need to worry about this?
But it would only reveal the size of the password, and you'd need to know the work factor, or the other way around, right? Or am I understanding it wrong?
Re: How To Safely Store A Password
#125Many developers need to read and understand this. It is far from mainstream knowledge... The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110 - No mention of bcrypt (though the posts mentions key stretching using SHA1) - "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm l…
I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never receive the plain text password?
Re: How To Safely Store A Password
#126Many developers need to read and understand this. It is far from mainstream knowledge... The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110 - No mention of bcrypt (though the posts mentions key stretching using SHA1) - "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm l…
Many developers need to read and understand this.
I note that the question was migrated from StackOverflow to security.stackexchange.com. After all, this is an issue that the security nerds care about. Why bother ordinary developers with it?
Re: How To Safely Store A Password
#127The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop. How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.
I guess by the time there are several users per second just authenticating, the $200 for a GPU that can boost hash performance 100x won't be the problem any more.
Re: How To Safely Store A Password
#128Many developers need to read and understand this. It is far from mainstream knowledge... The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110 - No mention of bcrypt (though the posts mentions key stretching using SHA1) - "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm l…
I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never receive the plain text password?
I'm no security expert either, but I'm guessing the real solution is SSL. If you hash passwords in javascript, a middleman could easily just look up the source of your application and decrypt the hashed password coming over the wire.
Re: How To Safely Store A Password
#129Earlier quoted context omitted.
with cuda and the cloud it's quicker to try all possible passwords (starting with aaaaaaa...) than to search a rainbow table of dictionary words so ":Hy6&z@z" is now no more secure than "password"
Rainbow tables don't apply to salted passwords.
But you can still do a brute force attack--that's part of why SHA1 has some issues--you can beat it with brute force and enough GPUs.
Re: How To Safely Store A Password
#130Many developers need to read and understand this. It is far from mainstream knowledge... The other day, I saw the following post about password hashing in my RSS feed: http://isc.sans.org/diary.html?storyid=11110 - No mention of bcrypt (though the posts mentions key stretching using SHA1) - "When selecting an algorithm to hash passwords, it is important to select carefully as it is difficult to change the algorithm l…
I know very little about security, but is there something wrong with using a hash in the client side and then using bcrypt on the server so that you never receive the plain text password?
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.