Honest question. Why would someone who handles more than a couple-dozen login attempts per second choose to use bcrypt? It would seem that the computational overhead of supporting bcrypt at scale would not make a lot of financial sense.
How To Safely Store A Password
161–170 of 215 posts
Re: How To Safely Store A Password
#162Earlier quoted context omitted.
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.
On the upside, it is an improvement for the use-the-same-password-on-many-services users, assuming the hash is not trivial to reverse like md5.
At this point, I'm less worried about somebody getting access to some random startup I signed up for than I am about them using the leaked password to gain access to my other accounts.
(I've recently changed my password scheme to using a different one for every service, but this just puts me within a minority.)
Re: How To Safely Store A Password
#163Earlier quoted context omitted.
It depends on the work factor. On my dev server (a pretty old machine), with a work factor of 7, it's about 300 time slower than md5 (about 10ms per bcrypt hash). That's still plenty fast, and much more secure. Bump it to a work factor of 9, and I'm looking at about 1000 times slower (or getting close to 40 ms per hash). Part of its beauty is you can adjust the work factor to match your hardware speed requirements. I…
bcrypt at 10ms only being 300 times slower would indicate you can only try 30,000 MD5 hashes per second -- which is incorrect. Using a GPU based cracker on a current generation top-end video card you can calculate over 300 million per second. Bcrypt at 10ms is 3 million times slower, not 300 times.
Your comparison is flawed - you're comparing GPU evaluation times for MD5 against CPU evaluation of bcrypt.
Re: How To Safely Store A Password
#164Previous post: http://news.ycombinator.com/item?id=1998819
Similar discussion: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...
Re: How To Safely Store A Password
#165I'd like to see sites offer the option of not using password-based authentication. Instead I'd like to see public key based authentication as an option. Basically, the site would have a copy of my public key (say my GPG key or an ssh key), and to authenticate I prove that I have access to the corresponding private key.
You've just described SSL with client certificates. Works perfectly well, is extremely secure, and has an extremely bad GUI in pretty much every browser ever. (It's somewhat difficult to use "on the road", but that's arguably a security feature.)
Easy to use on the road - don't use soft certs, use a smartcard! Works for every DOD network user around the world today...
Re: How To Safely Store A Password
#166Earlier quoted context omitted.
"you have to assume someone who stole your database also stole your code." Maybe, but that doesn't mean that a separate salt, not in the database, will prevent certain attacks, and as such is a viable option. Security is about layering, not about 'xyz isn't 100% secure in 100% of the cases, forget about it'.
That's fair, but it doesn't change the insanely wrong statement that triggered this comment chain: "sha1 with a salt u cant find beats bcrypt with a key u know any day" This is fractally wrong .
OK then we agree there :)
Re: How To Safely Store A Password
#167Earlier quoted context omitted.
With smartphones this is increasingly feasible. Lots of sites already use smartphone based two factor authentication (similar to rsa keys). There's no reason why a challenge / response system couldn't be set up using smartphones. For example, a website gives you a string of numbers, you input those in your smartphone app and get the response which yiu then input back to the site, the site can't determine the response…
This is how blizzard (World of Warcraft) authenticators work. It's quite ironic how an online game has strong security mechanisms, yet many tools that people use just as often or more (gmail, facebook, pretty much all SaaS tools, including business) and that are are certainly more 'important' (in an objective sense, I understand that people are more attached to their WoW character than to their customer database) don…
Facebook also has this feature. It'll send a SMS with the security code and you'll type in the web UI. Since it's SMS and not an app, it also works on non-smart phones. You need to link a mobile to your Facebook account.
https://www.facebook.com/help/?page=132501803490562
Re: How To Safely Store A Password
#168Earlier 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.
Exactly; Having a secret hash is just another example of futile security through obscurity. You want an attacker to be able to know as many parts of the puzzle as possible and still be thwarted.
Re: How To Safely Store A Password
#169Earlier quoted context omitted.
"Then how in the world does your code know what salt to use when the user presents his or her password?" It brute forces the missing part. Obviously you may only leave out a number of bits that keeps it feasible.
Or you could use something like bcrypt with a configurable 'cost' and stop making up things that you think will secure your passwords. Anything you can brute force with your hardware can be brute forced on someone else's hardware.
"Anything you can brute force with your hardware can be brute forced on someone else's hardware."
How doesn't this argument apply to increasing work factor in bcrypt?
Re: How To Safely Store A Password
#170Many 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…
not storing the password in sql has nothing to do with obscurity. In fact, it's smart.
You do not understand what "security through obscurity" means.
Following your train of though, we should display the salt and the hash publicly. That is extremely dumb.
Put your passwords in your post, otherwise you'll be doing security through obscurity! oh snap?