8 ms·
Enough with the Salts: Updates on Secure Password Schemes
- aidenn0 11y agoNot mentioned in the article, is why salting is important even if rainbow tables aren't part of your threat model: There is more than one reason, but they all boil down to one fact; two accounts with the same password will hash to the same value if you do not have a salt. As an example, if an attacker gets a dump of all the hashed passwords, the weak passwords will be immediately apparent just from an analysis of duplicates.
- firebird84 11y agoI almost feel as though this is at least half of the point of using salts. We're trying to make things slow, so forcing an attacker to crack the same password twice (or more) in cases where it's reused seems beneficial and very cheap. Weak passwords will still be cracked first but it will still require at least SOME work.
- hinkley 11y agoThat was the reason salts were used in /etc/passwd. You couldn't tell if John and James had the same password, and you couldn't tell if John used the same password on multiple machines. Or more critically, if the root password was the same on the entire cluster. As you two have already discussed, it mostly provides herd safety. You can't target the 'weak ones' because all the passwords look roughly the same.
- willvarfar 11y agoFurthermore, bcrypt, scrypt and the rest all have a salt. They just serialize it into the password along with the work factor etc.
- Semiapies 11y agoThat's kind of the point; if you're worrying at all about salts in your login code, you're using a crappy algorithm. If you're using a decent algorithm, it takes care of the salts.
- InclinedPlane 11y agoSort of a catch-22 though. On the one hand you want all of the important details about your password "encryption" system to be handled by more competent people (read: cryptographic experts). On the other hand, without an understanding of the details you will be too ignorant to tell the difference between a good and bad algorithm and in whom you can entrust such implementation specifics or not. Additionally, one might say "well, just follow industry best practices", but that is based on the idea that "use bcrypt/script" is such, but it's not. The "best practice" as defined by the industry at large is mostly just to use MD5, maybe with a salt, because that's what "everybody else is doing".
- davidrusu 11y agoIs anyone here using Scrypt in production? I had do decide on a hashing scheme recently and ended up going with Bcrypt just because of how new Scrypt is.
- Karunamon 11y agoI know Keybase (http://keybase.io http://keybase.io) uses scrypt, but that's the only one I know of off the top of my head.
- malgorithms 11y agoDetails, in case it's helpful/interesting to anyone: https://keybase.io/docs/api/1.0/call/login https://keybase.io/docs/api/1.0/call/login . Also of note, the hashing is done client side, not server-side.
- hinkley 11y agoDoesn't that mean the hash is the password, not the password? If I steal the password file what keeps me from just logging in as everybody?
- darkr 11y agoCan't vouch that this is the case with keybase, but where I've seen this done before, the hash is calculated in combination with some kind of time-based shared secret at both at the server and the client and then compared, with the theory being it would protect against the TLS connection is MITM'd; all the attacker would get is the hash, which is then useless as the time element isn't known. IMHO, MITM would be better defended against using HSTS, certificate pinning, and perhaps DNSSEC.
- nitrogen 11y agoIt seems like it would be better to just use SRP (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...). SRP defends against replay attacks, and could potentially use a modified bcrypt or scrypt for H() to limit brute force attempts.
- coldcode 11y agoOf course all this might go out the window once quantum computers become mainstream.
- dchest 11y agoHow so? Currently known symmetric crypto algorithms are secure against attacks by quantum computers. More than that, hash functions, which are building primitives of password hashing functions, are used in "post-quantum crypto", e.g. for signatures (https://en.wikipedia.org/wiki/Post-quantum_cryptography#Hash-based_Cryptography https://en.wikipedia.org/wiki/Post-quantum_cryptography#Hash..., http://sphincs.cr.yp.to/ http://sphincs.cr.yp.to/). (Although more research should be done on memory-hard functions.)
- mtgx 11y agoAren't some new password hashing schemes coming out now? https://password-hashing.net/ https://password-hashing.net/
- sarciszewski 11y agoThere's still some tweaks to be made to Argon2 before it's finalized. Mostly GPU resistance. Then there's the standardization for the crypt(3) format.
- zkhalique 11y agoThese days, what is wrong with rolling your own encryption of passwords using key strengthening and salting? Like this: hash = sha1 applied recursively 4071 times ( password . salt ) . salt Serious question. Don't just say religiously, "just use bcrypt". Tell me what is really wrong. What attacks will succeed today? Any crypto enthusiasts in the audience?
- mkozlows 11y agoThe non-expert answer is: Because crypto math is difficult for randos to analyze, and it's not obviously the case that running an algorithm 4,000 times is 4,000 times harder to break than running it once. And from a purely pragmatic perspective, why even consider it? You have a bcrypt/scrypt library, writing your own code is harder and almost certainly worse, so there is literally no reason to spend even a second thinking about it.
- zkhalique 11y agoYes, there are reasons to think about it. For example if I want to understand the principles that make the usual algorithm strong. There is a reason why Apple makes every app implement its own receipt validation scheme. So a dedicated attacker can't crack all apps at once. Same here.
- simcop2387 11y agoSo you essentially then end up with PBKDF2, as long as you're using an HMAC configuration with your hashing function you should be ok. That said, just go ahead and use a PBKDF2 library so that you match what others do and you have an easier time with interoperability if you have to use a different language or environment somewhere else with the same set of users. The reason you want to use HMAC is the same as always, it provides better security against a number of attacks that could recover the secret, https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security https://en.wikipedia.org/wiki/Hash-based_message_authenticat...
- deleted 11y ago[deleted]
- nsxwolf 11y agoSerious question: Why isn't there a "best practice" for this? A library everybody uses to store passwords in the most secure way possible, and when more secure ways are found, the library is updated and not your code? Everything is so low level, manual and error prone for such a basic part of app security.
- IgorPartola 11y agoDjango provides this and you don't have to worry about it. However, they did not for a bit, even as the discussions raged on about how salt + SHA1 is bad. The reason was that Django is 100% pure Python and at the time the only available implementations of any of this were C Python extensions. Ideally, I'd love to see bcrypt, scrypt, and PBKDF2 included directly in Python's stdlib so that people wouldn't have to re-invent the wheel every time they use the language.
- masklinn 11y agopbkdf2 is included in Python's stdlib since 2.7.8[0] and 3.4[1], though sadly the interface isn't great: it outputs the hash only, not a modular crypt[2] and it requires a salt instead of generating one. Passlib[3] provides more algorithms, a much better interface and handles hash migrations[4] ridiculously cleanly. [0] https://docs.python.org/2/library/hashlib.html#hashlib.pbkdf2_hmac https://docs.python.org/2/library/hashlib.html#hashlib.pbkdf... [1] https://docs.python.org/3.5/library/hashlib.html#hashlib.pbkdf2_hmac https://docs.python.org/3.5/library/hashlib.html#hashlib.pbk... [2] http://pythonhosted.org/passlib/modular_crypt_format.html#modular-crypt-format http://pythonhosted.org/passlib/modular_crypt_format.html#mo... [3] http://pythonhosted.org/passlib http://pythonhosted.org/passlib [4] increase of rounds # or KDF change http://pythonhosted.org/passlib/lib/passlib.context-tutorial.html#deprecation-hash-migration http://pythonhosted.org/passlib/lib/passlib.context-tutorial...
- mkozlows 11y agoThe library can't be updated automatically, because suddenly all your stored passwords wouldn't work. If it's a big monolithic library like Spring, they just deprecate APIs and add new ones (which is in fact what they do); if you're in a microframework language like Node, you're on your own to rip out your md5 module and switch it to bcrypt.
- nostromo 11y agoPeople need to read this article very carefully before forming any sort of take-aways. The title and the start of the article suggest that salts are irrelevant. Then only a few paragraphs later, the author states that salts are indeed crucial. Later in the article, we learn that this article isn't really about salts at all, but the importance of a high work factor / rounds. The problem with the way this article is presented is that a casual reader will be left with the idea that salts are no longer important, which is false. A better title would be something like, "Salts are important, but so is a high work factor"
- tptacek 11y agoCareful. Salt quality is almost totally unimportant. And there are no well-known, well-reviewed password hashes that aren't randomized. The lesson I'd take away from an article like this is: "don't DIY your password hash". Historically, every discussion I've seen that tried to acknowledge the "importance" of salts devolved into people defending their DIY "secret-salt" schemes. "Important salts" seem like an invitation to reject bcrypt, scrypt, and PBKDF2. I think part of the problem is the term. I think we should stop talking about "salts", and instead just say whether a given password scheme is randomized or not.
- markdown 11y agoGoogle AppEngine is part of the Google Cloud Platform. It's a pretty big deal. If you want to use it, (at least with Python) you need to roll your own. You can't upload scrypt, bcrypt or PBKDF2 with your app, since code with C isn't kosher on there.
- ixtli 11y agoInteresting side note: one of the most successful altcoins (a few years ago, back when people cared about this stuff) was called litecoin. The major difference is that it used scrypt instead of SHA because it was hard to parallelize. The idea was this would keep rich groups from taking over the network by throwing money at hashing clusters. I built a machine in a milk crate that had 5xR9s to mine it. I broke even and sold it after I got bored :) It was fun for a month or two.
- timo_h 11y agoThis was probably the most notorious misuse of scrypt. Memory usage of scrypt was tuned to take 128KB, which made Litecoin mining ~10 times faster on GPUs than on CPUs.
- ossreality 11y agoWhat a long drawn out way of saying that bcrypt > md5 and that that distinction is more important than the salt.
- zeveb 11y agoI never understand why PBKDF2 gets so little love. It's easy to use, it's easy to implement correctly, it's standardised. scrypt is cooler, but PBKDF2 is just fine.
- kijin 11y agoPBKDF2 is okay, but the underlying algorithms (usually SHA256) are a little too easy to accelerate with GPUs and ASICs. scrypt can also be accelerated with GPUs, but the difference is much smaller due to its design. PBKDF2 is still widely used in applications that need to be small and simple, such as embedded devices and disk encryption tools. For hashing website passwords, though, it is showing its age. Disclaimer: I'm not a cryptographer, so I might be talking out of my ass.
- zeveb 11y agoOh sure, scrypt is better than PBKDF2, but IMHO PBKDF2 is preferable to bcrypt, due to ease of implementation.
- kijin 11y agoThat depends on whether someone else has already implemented it for you. In PHP, for example, bcrypt is just `password_hash()`. To use PBKDF2, on the other hand, you have to generate your own salt and pass it to `hash_pbkdf2`.
- masklinn 11y agoscrypt has the advantage that it can be memory-tuned and is designed to be both CPU-hard and memory-hard. PBKDF2 and bcrypt are only cpu-hard. Though IME it's bcrypt which is considered cooler, scrypt is regularly mentioned in KDF discussions but not widely available let alone used. The big advantage of bcrypt is its cost factor is exponential rather than linear, so the changes in cost factor are much lower and less frightening (you need to double the pbkdf2 cost factor to double the cost, on bcrypt you just increase the cost factor by 1, to match Moore's Law you just need to increment the cost factor by 1 every 2 years). And that's ignoring pbkdf2 can also be tuned using the hash function. So is PBKDF2 just fine? Yeah, that's what I generally use. But it's easier to create a simple and correct interface for bcrypt, it has less moving part and the parts which do move move slower.
- Illniyar 11y ago"The multiple salts don’t really do much since they’re all likely known to an attacker or can be quickly calculated given knowledge of the other two component" I've never heard before that you can calculate the sitewide salt (i.e. in memory abd unknown to attacker) from having both the user password and the per-user salt. How is this done?
- dogma1138 11y agoThe same way you would calculate the password and if you knew the site salt and the per-user salt. Or the password in case there's just a user_pw+salt :) In that case it's simply that the "site salt" is the "password" you after it, since you know the 2 other variables you just randomly generate the 3rd one, hash it and see if it matches.
- Illniyar 11y agoExcept that salts do not need to be remembered and as such should and usually are randomly generated with high entropy and are unlikely to be brute forced like normal passwords.
- zaroth 11y agoThe second half of that sentence is false, assuming the site salt has enough entropy, i.e. 32-bytes from a CS-PRNG. However, if your server is compromised, pulling the site-wide salt (aka 'pepper') from memory is presumably trivial, so you typically assume it is known to the attacker.
- zaroth 11y agoSalt is a requirement but not a panacea. AshleyMadison's salted MD5 proves that well enough. The point of a salt is so that same password does not result in the same hash for two different users. The key point is that attack time scales linearly with user count, which makes a difference in the actual crack rate when the breach is large. When cracking passwords, to crack the most hashes, your inner loop is iterating the salts from the database while the outer loop moves down the dictionary. Crucially, that means the salt should always be the first bits fed to your hashing function, or else the cracker can optimize away some hashing cycles across users. HMAC will do the right thing here if salt is passed as the 'key' (although the way it expands the key to the block size is somewhat flawed). Feeding the salt to the hashing function first approximately halves the crack rate versus appending salt at the end, by preventing any reuse of hash function state in the inner loop. [1] [1] - http://article.gmane.org/gmane.comp.security.phc/2325/ http://article.gmane.org/gmane.comp.security.phc/2325/
- lucb1e 11y agoReading this title I was wondering what news they have over PBKDF2/Scrypt/Bcrypt and whether it would really be better. Read through it quickly and was disappointed. Unlike they claim, this advice was popular even in 2010: https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords https://security.stackexchange.com/questions/211/how-to-secu...