[Cryptography] The proper way to hash password files

Phillip Hallam-Baker phill at hallambaker.com
Thu May 22 19:54:21 EDT 2014


On Thu, May 22, 2014 at 3:06 PM, Hanno Böck <hanno at hboeck.de> wrote:
> On Thu, 22 May 2014 13:09:57 -0400
> Phillip Hallam-Baker <phill at hallambaker.com> wrote:
>
>> Lots of sackcloth and ashes as EBay loses a password file.
>>
>> It occurs to me that most of the time, machines do password files
>> wrong. Rather than using a salted hash, a better approach would be to
>> use a MAC with a randomly chosen key that is never disclosed.
>
> And now how do you guarantee that the key is never disclosed? I mean if
> you can do that you can also just make sure the password database gets
> never disclosed.

Well all cryptography ever does is reduce the volume of the problem.
Having to secure 128 bits is easier than securing 150MB.

I would definitely want a HSM involved and the same sort of chain of
custody controls that we have for traditional PKI. I would want to
talk to the HSM as a network service and have essentially two commands

byte [] validator EncodeNew (string password)
bool Verify (string password, byte [] validator)

The validator codes would be stored in secure storage of course but
they can't be attacked by brute force unless the HSM is compromised.

Salting does not make any difference unless the HSML is breached as it
is a 128 bit search space.

> This is the whole point I find annoying about the whole password
> hashing / saving debate: Basically, when your database gets stolen
> that's one of the worst things that can happen. And no amount of
> intelligent storage of passwords will change that.

Unless it can be fixed so that access to data secured in hardware is
required to decode.


More information about the cryptography mailing list