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

[Arnold Reinhold]

On May 27, 2014, at 3:03 PM, Phillip Hallam-Baker <phill at hallambaker.com> wrote:

> 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.

Right, but I am concerned with packaging and key management. I envision classic NSA style key management with the MAC key separated from any device that can communicate with the network and keys loaded by a mechanism that requires physical access to the module, and preferably prevents easy readout of the key(s) even if physical access is obtained. The MAC key becomes a very valuable secret in this model, on a par with the private keys used for enterprise financial transactions. The good news is that the protocol and proof of concept software can indeed be developed on a hobby-class processor. Packaging and key management are mostly orthogonal issues. 

The Netdulino may even be too powerful. It apparently has an operating system, I don’t want no stinken operating system, just a simple loop that looks for a message and issues a response. I was thinking of the $80 Mojo FPGA Development Board http://www.adafruit.com/products/1553. It has a Xilinx XC6SLX9 and a ATmega32U4 micro controller that can handle the USB communication. The Xilinx XC6SLX9 is way overkill for a MAC but the board has 84 digital I/O pins. I was thinking of having a secondary hardware key consisting of a daughter board randomly connecting 40 output pins to 40 input pins to produce a permutation function. log2 (40!)= 159.1 bits.  (A 32 bit permeation might be easer to use in an algorithm, log2 (32!) = 117.6 bits.) Or just have an 84-bit key programmed with dip switches. Ultimately, I’d like an ASIC to do the MAC and accept key-fill. 

The ATmega also loads the Xilinx firmware, so that is a potential attack path. It might be better to use a separate ATmega to handle the USB communications, but for starters, the Mojo board looks good to me. Power dissipation is low enough to lock the whole thing in a safe, maybe several modules, maybe with dual combination locks for two person integrity. The physical security stuff will dwarf the cost of the electronics.

> 
> 
>> 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.

The big advantage of having the new password hash mode generate the salt is that it then cannot be used as an oracle to crack passwords.  If the hash generation mode accepts the salt, then it can be used as a cracking tool. Creating the salt is easy enough and does not require a very sophisticated random number generator.

> 
> 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.

Ultimately applications will want to access this service over the network, but I agree the security module itself should not contain the complexity of a network stack. It should talk via the simple messages I described, maybe over USB, to a server or whatever that has the full network stack.  

> 
> 
>> 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.
> 
Not sure what you mean above.

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

I want a little data as possible coming out of the security module, maybe just an alarm signal if it sees too high a rate of queries. The server it is connected to can do any logging and more sophisticated attack detection and mitigation.

> 
> 
>> 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.
> 

Perhaps, but this issue is orthogonal to the basic design and more than one solution could be allowed.

> 
> 
>> 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.

I completely agree that an inexpensive solution should be possible and is worth building now. But the people who really need this, the Targets and e-Bays of the world, probably will insist on having all the CYA certifications imaginable, so it is worth designing with eventual certification in mind.

Arnold Reinhold