[Owasp-leaders] Stepping through password hashing options
caughron at gmail.com
Sun Jun 24 15:23:02 UTC 2012
The guidance also needs to include how to handle iteration properly IMO.
On Jun 24, 2012 10:13 AM, "Jim Manico" <jim.manico at owasp.org> wrote:
> 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>
> > 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
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders