9

I'm trying to convince higher-ups on a project to use an iterative strengthening function to secure password-storage for a new system. The current proposal would store something like an HMAC of a salted SHA-256 (presumably the other HMAC inputs are being stored separately for bonus security).

The security developers speak a different language so it's basically impossible to communicate with them directly, or determine exactly the requirements. I went straight to the higher-ups who only seem to understand business case studies. I've been told amid my protestations that basically the only way to convince them would be to find some real-world examples of major password leaks that used both a salt and HMAC but not iterative strengthening, and had many passwords compromised as a result.

Please understand I'm not going to try to attain the impossible and get them to implement the exact standard recommendations for password storage. I just want them to consider iterative strengthening.

Are there any prominent real-world examples where salt and HMAC were used, but due to lack of iterative strengthening, many passwords were compromised anyway? Bonus points for well-known companies such as Facebook, LinkedIn, etc.

machine yearning
  • 203
  • 1
  • 5

4 Answers4

6

Perhaps it's also important to point out the breaches that have occurred where there was no evidence of compromised data. LastPass, for example, used "5,000 rounds of PBKDF2-SHA256" and a random salt (https://blog.lastpass.com/2015/06/lastpass-security-notice.html/). Since the breach, there have been no indications that the master passwords were broken.

That's not to say that we will ever necessarily know if the database is broken. If, for example, the database was exfiltrated and resides on a user's machine it doesn't mean that he will post successfully cracked passwords to Pastebin.

It would be a good segue to introduce the idea with the statement that minimal user accounts would be compromised before a password reset is issued. Thus reducing risk and legal liability.

pr-
  • 782
  • 1
  • 4
  • 21
5

I do not believe you will find examples of a breach/password cracking as you have requested. HMAC of a 256bit SHA-2 salted hash is currently consider acceptably strong to meet, for example, NIST standards for the federal government. [The federal standard requires that the HMAC is at least 112 bits, BTW.]

However, your concern has merit, IMO, for the longevity of the solution. SHA-2 is being phased out. SHA-3 was officially published by NIST 2 months ago. FIPS202 The approach your colleagues advocate is last generation, so it should be fine for a while, but it won't have a long life before being officially deprecated.

BTW, iteration of a hash function is a well established way to strength protection, but it should be noted that it only provides linear value against a brute force attack, assuming the attacker knows the number of iterations. Likewise, anyone not salting their hash should be drummed out of the ranks of software developers, but salt only protects against table based attacks. Today and certainly going forward, the real problem is brute force. Password length and complexity requirements are the most important protection and 2FA must be considered for all sensitive access.

JaimeCastells
  • 1,156
  • 1
  • 9
  • 16
  • I am under the impression that SHA-3 has hardware implementations that run much faster than can be created for SHA-2. Therefore iterative strengthening is much more of a requirement if using SHA-3. Great answer btw. – machine yearning Oct 12 '15 at 17:22
2

This isn't how this kind of decision should be handled.

A security measure is a tradeoff between usability, cost and security. In order to evaluate a risk mitigation technology, you need to evaluate all three elements of that choice:

  • How difficult is it to use the technology, both for users and for the people deploying and manging it?
  • How effective is that solution at mitigating a specific risk ?
  • How much would it cost to implement and operate that technology ?

In your case, using an industry-standard password derivation system probably has a very minor impact on usability: unless you are using very restrictive devices, the impact on the users (all of them) is most probably negligible.

Adding that key expansion step, in itself, provides two security benefits: it makes it quite a bit harder to crack a specific password through brute-force and, if you use a standard password derivation function, it also puts you on very firm ground to say that you used all possible measures to protect your users (which, in case of a password breach, isn't a minor factor when attempting to regain trust).

As for the cost, it really depends a lot on how your system is built: adding a long, mandatory computing phase to an operation will most likely increases your infrastructure costs: you will need more CPU cycle to handle the same number of user authentication requests. How much exactly, of course, is something only you can figure out.

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • I'm well aware of everything you mentioned. It would be easy to implement, would have incredible benefits, and the key expansion would be parameterizable so we could decide how much CPU cycle and memory overhead the method would cost. Unfortunately management decisions are not always made based on how things "should be handled". Your answer although correct is not very helpful to me, it's basically contained in what I've already expressed to them. – machine yearning Oct 12 '15 at 15:20
0

OWASP has a great Password Storage Cheat Sheet. These guidelines are basically what most information security practitioners would recommend to their clients. Be sure to see the section on work factor.

Also, see this post on How to Securely Hash Passwords

Scott Johnson
  • 231
  • 1
  • 7