[Cryptography] [PHC] Re: The proper way to hash password files

[Phillip Hallam-Baker]

On Tue, May 27, 2014 at 2:07 PM, Arnold Reinhold <agr at me.com> wrote:
> On Mon, 26 May 2014 21:53 Phillip Hallam-Baker wrote:
>
>> At this point a more important step would be to write a protocol that
>> allows us to talk to a network based HSM password checker.
>
> While for low volume applications, key stretching with sufficient work factor, along with some enforcement of password standards, e.g. a minimum acceptable size and not on standard cracking lists, may be reasonably adequate, for high volume or high security applications we have to recognize that there is no solution that just involves software running on the enterprise servers. Some specialized hardware will be required.


Netdulino 2 Plus is $60... All we need this to do is a MAC.


> My vision of a password security server module would use a keyed MAC of the password and salt to form the hash to be stored as the password authenticator in the user’s record on the enterprise database. The key or keys would be stored in a hardware module in a way such that the keys would not be accessible to the network.

I think the salt should maybe come from the party that interns the
password value.

Problem with the device being a network device is that then it ends up
having a network stack. And that is a lot of complexity to check.


> The password security server would accept a fixed size message consisting of return address for the application requesting authentication, request number, the plaintext password, stored hash, salt, key number, and perhaps a time stamp for auditing. The password security server would calculate the keyed MAC of the password and salt using the secret key identified by the key number. The calculated hash would be compared to the one in the message. The server would then return the request number and a match/no match response.

Can do a further hash to the password certainly.

The Netdulino has an onboard SD card, maybe write the log out to it
and stop answering queries when it is full.


> The actual user ID corresponding to the password would not be transmitted, so intercepting the request on the network would have limited value, though an attacker who penetrates the network might also be able to see who is currently logging in. To reduce that risk, the authentication request message might be encrypted using a public key belonging to the password security server.

No, the user ID definitely not needed.

Not sure that I would want to do public key though. I am thinking that
a kerberos style solution would be better.



> Off the shelf HSMs might be adaptable to this application, but the underlying hardware could be much less expensive, perhaps consisting of an FPGA  with a microprocessor front end that dealt with the network and only passed fixed size messages to the FPGA. The microprocessor could check that the request number on the response message matched the request number of an incoming message, so that there would be minimum opportunity for leakage. The FPGA board would be designed so that firmware and key loads would require physical access, perhaps using unique connectors. The biggest expense might be getting full FIPS-140 certification for the module.

I would prefer a $60 solution that could be deployed now than a
FIPS-certified solution in 4 years.

Plus would have to be sure FIPS describes relevant controls.