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

Arnold Reinhold agr at me.com
Tue May 27 14:07:34 EDT 2014


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. 

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. 

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.  

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. 

A separate message type, possibly to a separate server, would be used to calculate the hash when a new password is created, accepting the plaintext password and returning the hash value, salt and key number. These would then be stored in the enterprise database. Since the password server also generates the salt, the response would be of limited value to an attacker.

The key number selects one of several keys. The password security server could store a large number of keys, perhaps even an SSD full, making it difficult for the secret hashing keys to be leaked, say via side channel attacks. The password security server would need features to prevent a rogue program inserted into the network from using the password security server to do key cracking. These might include limiting the number of responses per minute, perhaps based on expected usage patterns, and maintaining an audit trail. Note that the password security server would not see user IDs, just a request number generated by the application, which would be responsible for keeping track of the requests. 

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.

Arnold Reinhold


More information about the cryptography mailing list