<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 22, 2014 at 10:09 AM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rather than using a salted hash, a better approach would be to<br>
use a MAC with a randomly chosen key that is never disclosed.<br></blockquote><div><br></div><div>That's fine if you keep the key in something like an HSM, but a key disclosure would be catastrophic as an attacker could use it to brute force the password database much more easily than if a password hashing function like bcrypt or scrypt were used. Without a salt to make each brute force attempt specific to an individual password, a dictionary attack on the key would allow you to attack the entire password database simultaneously.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now this seems obvious but I can't recall ever seeing code set up to<br>
do the job this way...</blockquote><div><br></div><div>Many of the Password Hashing Competition entries included an additional key parameter, referred to as things like "pepper" or "garlic". The main concern here was cache timing attacks.</div>

<div><br></div><div>HMAC is nice in that it could be done by an HSM and is relatively trivial. You could combine an HMAC of the original password, then feeding the HMAC result into a standard password hashing function. This would help mitigate brute force searches even if the key were compromised, and would also help mitigate some more exotic things like cache timing attacks on the password hashing function.</div>

<div><br></div></div>-- <br>Tony Arcieri<br>
</div></div>