[Owasp-leaders] Stepping through password hashing options
jim.manico at owasp.org
Sun Jun 24 17:22:46 UTC 2012
Symmetric encryption based password storage, ie: reversible password
storage, is something that I rarely see recommended. But I can certainly
see situations where it is prudent.
I think that key management is one of the most difficult aspects of any
crypto storage system; it's not an easily achievable goal for many dev
shops, especially on a scale that you are considering.
I would also say that reversable password storage falls within the confines
of traditional cryptographic storage and key management ala the
cryptographic storage cheat sheet (key rotation, out of band re-keying of
I still think it's critical that we resolve the issues with one-way
password storage as well - I think it's a much more important use case. But
I agree that both of these designs are prudent based on the situation.
Off to your threat model...
On Jun 24, 2012, at 5:46 PM, John Steven <John.Steven at owasp.org> wrote:
Last week I completed an informal threat model on this topic and remain
convinced of what I was prior to this entire LinkedIn discussion:
1) Several alternative password protection protocols between a party S (app
server) and D (database) perform similarly. That is: several protocols fall
within an equivalence class in terms of resisting defined threats & attack
2) Protocols leveraging a secret key, applied to a transform on S (app
server), maintain several advantages over [only] custom salted schemes IFF
properties of compartmentalization (S separate from D) and separation of
privilege (between access to S and D) hold. Specifically:
2.A) The S(k) (secret key) is available to fewer attack surfaces than U(s)
2.B) S(k) provides a larger defender advantage towards making brute-force
attacks intractable due to 'search space' than U(s);
2.D) S(k) produces a larger defender advantage in terms of cryptanalytic
attack in the face of known plain-text/cipher-text combinations.
***NOTE: Comparing adaptive hashes and ciphers in terms of throughput is
dubious without fixing additional parameters (see #3);
3) While Adaptive hashes (*1) can be configured to provide throughput
advantages to the defender over keyed ciphers, this advantage appears to
come with compulsory tradeoffs in the form of three elements:
* CPU-hardness (i.e. throughput of the operation)
* Memory-hardness (i.e. space required to perform operation)
* Space/time required for brute forcing based on scheme inputs
I can't seem to mitigate negative side-effects of the above in design:
3.A) Threat gains advantage towards successful DoS (or at least
defender suffers unacceptable latency as per existing customer SLA).
3.B) Defender given no advantage relative to threat model equivalence
class defined by item #1.
3.C) Defender loses 'reversibility' and R/W privilege-separation over
based solutions (symmetric or asymmetric)
[Can't Conduct Secure Design Tradeoff Analysis w/o Agreeing on a Threat
You can find a more complete view of threats and attack vectors in the
Feedback welcome. Since I'm doing this in my spare time, expect the design
portion of the document to be completed next week. Expect v0.1 of Java code
to be available after review and iteration.
[Dev-Ops and Resilience]
One aspect of secure design that's been largely ignored by the AppSec
community as part of this discussion is resilience: a system be built with
the understanding that successful attack will [eventually] occur. The
system should enable its maintainer to continue to conduct business
uninterrupted while they 'explore' and 'fix' a problem such as bulk PW /
digest exfiltration. I define this in the document above as a 'rule of
PSM ‘resilience’ graded in terms of site owner ability to continue
> providing services in the face of [T1.AV1] or [T3.AV1] (bulk compromise of
> <protected>(PW) for all [V2]) through goals of key/scheme rotation [SOKR] &
> compensating controls;
When you think about it: this is one of three reasons the software should
1) Compromise (above)
2) Key rotation policies
3) EoL a scheme/key-strength (i.e. due to advances in CPU, storage, or
Since I hear rumblings of Dev-Ops and "Rugged" development in this
community this omission surprises me a bit.
On Sun, Jun 24, 2012 at 10:11 AM, Jim Manico <jim.manico at owasp.org> wrote:
> 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.
> On Jun 11, 2012, at 3:03 PM, William Stranathan <will at thestranathans.com>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders