<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 27, 2014 at 2:07 PM, Arnold Reinhold <span dir="ltr"><<a href="mailto:agr@me.com" target="_blank">agr@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Mon, 26 May 2014 21:53 Phillip Hallam-Baker wrote:<br>
<br>
> At this point a more important step would be to write a protocol that<br>
> allows us to talk to a network based HSM password checker.<br>
<br>
</div>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.<br>

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

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

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

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

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

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

<span class="HOEnZb"><font color="#888888"><br>
Arnold Reinhold<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">If I understand this thread correctly (which is often not the case), the basic idea here is to use a special non-disclosed master key to scramble password hashes even more, making it impossible for an offline attacker without the master key to brute force guess any passwords.  This is a great idea, and should be encouraged, IMO.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">This was discussed on the PHC forum (I first learned about it from the Blakerypt paper posted there), and several of the entries, including Catena, Yescrypt, Lyra2, TwoCats and others, support site-specific data fields that get hashed into the password, which can be used to support master keys.  I mention that as my favorite use for the extra parameter in my TwoCats submission.  Even with Yescrypt (the entry with the most defense features), use of such a key is probably a good idea.  A password authentication server with a 1TiB ROM still loads that ROM from disk, and if an attacker gains physical access to it (during maintenance for example), having a master key that never hits disk could be a good thing.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think for large web sites like eBay, I'd prefer an authentication server with a mongo ROM and lot's of defensive features, rather than a cheap USB/FPGA key.  However, for all the guys out there (like me) who couldn't realistically justify an authentication server costing many thousands of dollars, a cheap USB-dongle sounds good.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I like the idea of using an FPGA and a microcontroller, and making it all open source and easily verifiable.  I'd say just use a Raspberry Pi or work with the FreedomBox guys, if they were more easily verifiable.  Such a dongle could also potentially be used for micro-transactions and other applications, in addition to hashing passwords, or SRP.  They could be used as secondary authentication factors, too.  If we had a second access port on the "secure" side, maybe it could be used for secure end-to-end encryption (or even VPN) between parties who each have one.  I can think of lots of uses for such a device.  I want one :-)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Bill</div></div>