Enough with the Salts: Updates on Secure Password Schemes

Not mentioned in the article, is why salting is important even if rainbow tables aren&#x27;t part of your threat model:<p>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.<p>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.

People need to read this article very carefully before forming any sort of take-aways.<p>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.<p>Later in the article, we learn that this article isn&#x27;t really about salts at all, but the importance of a high work factor &#x2F; rounds.<p>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.<p>A better title would be something like, &quot;Salts are important, but so is a high work factor&quot;

Salt is a requirement but not a panacea. AshleyMadison&#x27;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 <i>when the breach is large</i>.<p>When cracking passwords, to crack the most hashes, your inner loop is iterating the <i>salts</i> 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 &#x27;key&#x27; (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]<p>[1] - <a href="http:&#x2F;&#x2F;article.gmane.org&#x2F;gmane.comp.security.phc&#x2F;2325&#x2F;" rel="nofollow">http:&#x2F;&#x2F;article.gmane.org&#x2F;gmane.comp.security.phc&#x2F;2325&#x2F;</a>

Serious question: Why isn&#x27;t there a &quot;best practice&quot; 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?<p>Everything is so low level, manual and error prone for such a basic part of app security.

Interesting 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.<p>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.

Is anyone here using Scrypt in production?<p>I had do decide on a hashing scheme recently and ended up going with Bcrypt just because of how new Scrypt is.

I never understand why PBKDF2 gets so little love. It&#x27;s easy to use, it&#x27;s easy to implement correctly, it&#x27;s standardised. scrypt is cooler, but PBKDF2 is just fine.

Reading this title I was wondering what news they have over PBKDF2&#x2F;Scrypt&#x2F;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: <a href="https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;211&#x2F;how-to-securely-hash-passwords" rel="nofollow">https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;211&#x2F;how-to-secu...</a>

&quot;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&quot;<p>I&#x27;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?

These days, what is wrong with rolling your own encryption of passwords using key strengthening and salting?<p>Like this:<p>hash = sha1 applied recursively 4071 times ( password . salt ) . salt<p>Serious question. Don&#x27;t just say religiously, &quot;just use bcrypt&quot;. Tell me what is really wrong. What attacks will succeed today? Any crypto enthusiasts in the audience?

Aren&#x27;t some new password hashing schemes coming out now?<p><a href="https:&#x2F;&#x2F;password-hashing.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;password-hashing.net&#x2F;</a>

Of course all this might go out the window once quantum computers become mainstream.