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

[Bill Cox]

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.
>
> 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
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>

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.

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.

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.

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 :-)

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140527/dea87403/attachment.html>