[Owasp-leaders] Stepping through password hashing options

Jim Manico jim.manico at owasp.org
Sun Jun 24 18:35:59 UTC 2012

Your threat model is the best work on password storage design I have
seen to date. I get it now, and I'm in 100%.

Hey world, time to unlearn what you have learned about password storage. :)

Stay tuned, more to follow.

Jim Manico
(808) 652-3805

On Jun 24, 2012, at 6:36 PM, John Steven <John.Steven at owasp.org> wrote:

> Jim,
> Agreed. I was disappointed when I looked into solutions on-line and
> saw that package maintainers punted the hard problems (such as
> rotation, key storage, and so forth). The solution I donate will not
> punt these problems and will support a stand-alone operation that
> provides tools for quick setup of a "hello world" as well as
> scheme/key/db maintenance.
> (See below).
> -jOHN
> On Jun 24, 2012, at 1:22 PM, Jim Manico wrote:
>> 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.
> You inherit a key management 'security regression' whether you adopt
> PBKDF2, or [b|s]crypt (with a keyed-hmac) as well.  The threat model
> mandates a keyed-<transform> if you desire keeping the difficulty of
> reversing an individual user ([V1]) password above the
> complexity/length of the PW once the salt is known.
>> 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.
> Agreed. I argue in my last blog entry that if you're going to stay
> with a broken and constrained solution that PBKDF2() performs
> as-well-as the alternatives against documented threats/attack vectors
> IFF well-keyed and IFF separation of privilege holds (no defined AV
> opposes these assumptions).
>> On Jun 24, 2012, at 5:46 PM, John Steven <John.Steven at owasp.org> wrote:
>>> All,
>>> Last week I completed an informal threat model on this topic and remain convinced of what I was prior to this entire LinkedIn discussion:
>>> [Echo-chamber?]
>>> 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 vectors.
>>> 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) (user-
>>>        specific salt);
>>> 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 cipher-
>>>       based solutions (symmetric or asymmetric)
>>> [Can't Conduct Secure Design Tradeoff Analysis w/o Agreeing on a Threat Model]
>>> You can find a more complete view of threats and attack vectors in the following document:
>>> https://docs.google.com/document/d/1_XDb4O84VGW95NFHFQhr87Bq6PnKhmNE3RkxEzJnYnU/edit
>>> 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 engagement':
>>> 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 handle rotation/maintenance:
>>> 1) Compromise (above)
>>> 2) Key rotation policies
>>> 3) EoL a scheme/key-strength (i.e. due to advances in CPU, storage, or cryptanalysis)
>>> Since I hear rumblings of Dev-Ops and "Rugged" development in this community this omission surprises me a bit.
>>> -jOHN
>>> --
>>> Phone: 703.727.4034
>>> Rss: http://feeds.feedburner.com/M1splacedOnTheWeb
>>> 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)
>>>> and
>>>> 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> wrote:
>>>>> 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.
> --
> Phone: 703.727.4034
> Web: http://profiles.google.com/m1spl4c3ds0ul
> Rss: http://feeds.feedburner.com/M1splacedOnTheWeb
> _______________________________________________
> 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