7 ms·
Ignore this and see tptacek's post about bcrypt instead. This is why my preferred hashing scheme is username + seed + password, so that even if user1 and user2
by andrewjshults 16y ago
Ignore this and see tptacek's post about bcrypt instead.
This is why my preferred hashing scheme is username + seed + password, so that even if user1 and user2 both use "password" as their password, they'll end up with different hashes. That way if the database is compromised you can't do frequency analysis against the hashes to make guessing common passwords easier.
- tptacek 16y agohttp://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- andrewjshults 16y agoRegarding bcrypt - does it still make sense to do seeding on those since the key wouldn't be changing? I've also seen wrapping sha1/etc and looping it like 1000+ times to introduce a time factor in, but that doesn't seem like the best solution.
- tptacek 16y agoNo. Bcrypt does all of this for you.
- chime 16y agoSuppose I'm not able to use bcrypt for legacy reasons. Would a hash of username+password+constant_seed be good enough? What about user_dependent_seed+password+constant_seed? The user_dependent_seed could be a concat of username, account setup date, user id# etc. What hashing algo would you recommend if bcrypt is just not available?
- cheald 16y agoThe attraction of bcrypt is that you can tune its work factor to counter increases in computing technology, so that it's very slow to brute-force compared to an MD5/SHA/CRC, all of which are extremely fast to compute. It's counterintuitive, but the idea is that if Joe Blackhat gets your password hash, he's going to spend orders of magnitude more time chewing on it to get a result than if it were hashed with a fast hashing algorithm. Adding more salt to the hash is going to increase its time-to-crack, but swapping SHA1 for bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power.
- chime 16y agoI agree why bcrypt is much, much better. No doubt about that. My question was whether there was something I could do to improve security (even if marginally) on platforms that can't/don't support bcrypt. > bcrypt gets you a future-hardened algorithm that can be adjusted in responses to gains in computing power. How would I be able to change the cost factor overtime? I don't store my user's passwords. Should I just re-bcrypt the bcrypted password using a higher cost and in my login_verify code, take that into account? Or is there something else you can do overtime to raise the cost factor?
- bigiain 16y ago"How would I be able to change the cost factor overtime?" One system I built stores the workfactor used to bcrypt the current password un the user table, and allows me to increase the "system workfactor". Every time someone successfully logs in with a lower-than-current-workfactor password hash, it recomputes a new bcrypted hash using the currently known successful login password and updates the users credentials. It means if my user table is ever exposed, all frequently used accounts have up-to-date workfactors for their password hashes, and the "relatively weaker" hashes are for infrequently used (or, in this particualar case, expired subscriptions).
- ErrantX 16y agoIterate MD5 several times (i.e. 50 or so). That will introduce a similar "slow" factor (it's not a solution, but a stop gap) EDIT: I've also recommended using a random salt for each password too, but this is only a layer of security if you're code is not also stolen, then it is simply a slight additional "slow factor"
- ErrantX 16y ago(I'm not sure why I said MD5... what can I say it was a monday morning :))
- ErrantX 16y agoIf anyone has a comment as to why this is not good advice (it honestly is decent advice if you really insist on not using Bcrypt) then I'd be happy to hear it ;)
- anthonyb 16y agoBecause md5 is stupidly fast, even if you use a thousand cycles. As if that's not bad enough, there are FPGA implementations (http://nsa.unaligned.org/ http://nsa.unaligned.org/) which are even faster and relatively easy to come by.
- ErrantX 16y agoYes, MD5 was a mistake :) I was tweaking our cluster's MD5 implementation so it was stuck in my mind. Just sub in "hash function". You could up the iteration however much is needed (say, 1000, 10,000). It's poor security countermeasure, but it was a specific scenario :) The general idea is to combine salting and iteration to produce a poor mans slow hash. (which works great for software you're distributing for use on random shared architecture a la wordpress - just to give an example) Use Bcrypt where you can.
- anthonyb 16y ago
- narsimham 16y agoHow do I go about using bcrypt in php?
- tptacek 16y agoGoogle: [bcrypt php]
- narsimham 16y agothat is a bad answer. the search results from google are all added code, but php supports it natively: http://ca.php.net/manual/en/function.crypt.php http://ca.php.net/manual/en/function.crypt.php
- epochwolf 16y agoThis is not correct! PHP does not do bcrypt natively. Look at the supported options! Edit: crypt -> bcrypt, stupid iPad autocorrect
- nanexcool 16y agohttp://www.openwall.com/phpass/ http://www.openwall.com/phpass/
- leftnode 16y agoIs the seed a sitewide one or unique per password?
- andrewjshults 16y agoSince the username is unique, I tend to use a sitewide seed. My understanding of the seed is to make rainbow tables useless, so adding any unique data should help with that. Granted, now that you can fire up a GPU instance on EC2 and generate SHA1's like a madman, bcrypt does seem to be the way to go, but at least (as far as I can tell, would love to hear if my reasoning is incorrect) by including the username + password, you'd need to generate those rainbow tables against each user.
- cheald 16y agoThat's correct, but as you pointed out, with massively parallel cloud computing available for so cheap, you really want a slow function to shove that data through.
- deleted 16y ago[deleted]