5 ms·
I've been trying to find this out also. There's no indication that they are; but the only indication that they aren't was them saying that shorter passwords wil
by estel 16y ago
I've been trying to find this out also. There's no indication that they are; but the only indication that they aren't was them saying that shorter passwords will be much less secure.
- andrewjshults 16y agoIgnore 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"
- 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]