3 ms·
> Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are managing data. We
by eat_veggies 8y ago
> Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are managing data. We use more advanced methods like salted hash and SHA2 on securing users’ data in our database.”
!!!!!!
- 908087 8y agoDon't worry, they also double ROT13 everything.
- spydum 8y agoWhile SSHA2 isnt that bad if they’ve applied a work factor, but that’s probably not the case.
- shawn 8y agoIt's probably better to list what the real solution is: Bcrypt or scrypt. https://www.npmjs.com/package/bcrypt https://www.npmjs.com/package/bcrypt I also added it to a fork of Arc that I'm managing. https://github.com/shawwn/arc3.2/tree/ln/src/bcrypt https://github.com/shawwn/arc3.2/tree/ln/src/bcrypt (Just type `make` and then run Arc like usual. Which is `racket -f as.scm`.) Thanks to Scott Bell for providing code examples of how to use the racket FFI interface and unix crypt function, and for glancing over the finished code. That leaves the question of what an appropriate bcrypt work factor is. 10 is apparently about right.
- tprynn 8y agoIt doesn't matter what algorithm you use to hash passwords when users login if you also store them md5-ed somewhere else!
- wyldfire 8y agoTsk, but this was an upgrade from the old log that stored the first three letters of the passphrase. ;)
- deleted 8y ago[deleted]
- farazzz 8y agoIsn’t SHA2 the standard hashing algorithm? If not, what do people use now?
- Thriptic 8y agobcrypt is one example: https://auth0.com/blog/hashing-in-action-understanding-bcrypt/ https://auth0.com/blog/hashing-in-action-understanding-bcryp...
- hamandcheese 8y agoFor password hashing, you want the operation to be slow. That way it becomes infeasable for someone to brute force many passwords. SHA2 is very fast.
- deathanatos 8y agoIf I get any of this wrong, I claim Cunningham's Law. :) From the "Cryptographic Right Answers" [https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html#password-handling https://latacora.micro.blog/2018/04/03/cryptographic-right-a...]: > Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2. > Avoid: SHA-3, naked SHA-2, SHA-1, MD5. SHA2 is a decent cryptographic hashing algorithm, that is true. But a cryptographic hashing algorithm isn't what you want when storing passwords, at least, not on its own. Some of the problems with just using a hash algorithm: same passwords have the same hash; hash algos are typically fast, so brute forcing can make many attempts quickly, and they can be pre-computed into rainbow tables. There are ways to fix this (salts, work factors), but generally you shouldn't "do it yourself."; functions like those named in the quote from Cryptographic Right Answers put all that together in a nice package. scrypt, I believe, even uses SHA-2 in its construction, but also solves the aforementioned problems. The "Purpose and operation" part of the Wikipedia article for PBKDF2 (also mentioned above) goes into some of this, as well (even if it is only recommended as a last resort, I think this paragraph is educational w.r.t. the problems around passwords): https://en.wikipedia.org/wiki/PBKDF2#Purpose_and_operation https://en.wikipedia.org/wiki/PBKDF2#Purpose_and_operation
- shawn 8y agoSHA2 is fine for guaranteeing integrity. But that's different from coming up with a way to store a password that can't be brute forced in a small amount of time. The goal is to make the hashing function expensive. That is a different goal than making it reliable or authentic.