7 ms·
So, were these "passwords" stored as salted hashes?
by ShabbyDoo 16y ago
So, were these "passwords" stored as salted hashes?
- estel 16y agoI'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).
- 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]
- deleted 16y ago[deleted]
- wippler 16y agoFrom the readme.txt file, Gawker uses a really outdated hashing algorithm known as DES (Data Encryption Standard). Because DES has a maximum of 8 chars using a password like "abcdefgh1234" only the first 8 characters "abcdefgh" are encrypted and stored in the database. If your password is longer than 8 characters you only need to enter the first 8 characters to log in! Is this true? I tested it now and it needed the full password for a successful login.
- tptacek 16y agoDES crypt (I don't know that that's what they're using) is better than salted SHA1, vis a vis crackability.
- bbatsell 16y agoI'm not a cryptographer by any means, so please forgive and correct any errors. I'm assuming you're just saying that building rainbow tables once you have a static salt and the hashes becomes a feasible proposition? Wouldn't using a dynamic salt with each hash make a full dump like this significantly less crackable than DES with several weaknesses and a 56-bit cipher? (And that's, of course, assuming that the DES key doesn't leak along with the dump.)
- tptacek 16y agoDES crypt(3) doesn't have a "key"; it truncates/pads passwords into a DES key used to encrypt (with a salt) an all-zeroes block. It's horrible cryptography, but it's slower than SHA1.
- tzs 16y agoHow so? People have found collision attacks on SHA1 that are significantly better than brute force, but I thought it was still safe against finding a plaintext that hashes to a given hash value.
- brandon 16y ago