[Owasp-leaders] Stepping through password hashing options

Jim Manico jim.manico at owasp.org
Sun Jun 24 14:11:39 UTC 2012

Awesome, William.

Several cryptographers have slammed the idea of salt isolation (which
you and I both seem to be a fan of). Practically, I think it's a
powerful way to make password storage mechanisms more secure.

Also, several folks have slammed the idea of "building your own
crypto" which in my opinion you are NOT doing.

Both of these suggestions:

bcrypt(user salt + config salt + password, work-factor)


sha/fast-hash(user salt + config salt + password, iteration count)

Are less than 10 lines of code and are much more secure than the
common suggestion of "just use bcrypt" or "just use "PBKDF2".

Some additional caveats on bcrypt:
1) Blowfish derived, a big no-no for some crypto standards like FIPS
2) The work factor of bcrypt for some languages (like ruby) is way to
low/fast. We need to recommend a specific work factor, like 10, I
think. (Same for SHA-based storage, we need to recommend a specific
iteration count or time-to-compute).

Last, I see some folks wanting to recommend a reversible password
storage mechanism (ala symmetric crypto). Although this might be
necessary for some organizations, I do not think we want to address
this in the password cheat sheet.

Just my thoughts on this topic. John Steven and Kevin Wall are deep in
discussion coming up with a next gen password storage mechanism and I
am eager to see the fruits of their work.


Jim Manico
(808) 652-3805

On Jun 11, 2012, at 3:03 PM, William Stranathan <will at thestranathans.com> wrote:

> Jim:
> As the Mozilla document says, the point of BCrypt is to be slow to
> reduce the possibility of brute-forcing. I'm with you, however, and
> think there are downsides to this (DoS, login timing check attacks,
> etc.) that are generally mitigated by:
> 1) Use TWO salts - one in the db specific to the one credential and
> one in the application (in configuration, never in the code). As the
> Mozilla document states, the point of this is that if the attacker
> gets the DB, they don't get the salt. My approach has always been to
> keep two salts and use them concurrently on each round or on
> alternating rounds
> 2) Use a large-ish number of encryption rounds (depending on the
> algorithm). The way the salt is appended/prepended/injected should
> change each round.
> But again - you're spot-on in the summary - passwords are dead (at
> least I hope). As much as possible, I personally use passphrases and
> MFA.
> --
> -- coleslaw
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders

More information about the OWASP-Leaders mailing list