1

Due to an ongoing discussion in my office, I was wondering if anyone had any comments on whether password hashing security needs to be very strong if client certificate validation is also required for account verification.

We use SHA-512 hashing with a randomized salt for password storage. It has been suggested that we don't need to iterate the hash function as we require BOTH password and a client certificate for user validation.

Is our account security significantly lower if we reduce the number of hash iterations taking into account we also require client certificate validation?

Since in some some cases we allow certificate-only validation, and in SOME cases (i.e. on developer machines) we allow password-only validation, I'm tempted to suggest that we allow a low number of iterations (or no extra iterations) of the hashing method for users that require client certificate validation, but require a normal number of hash iterations for users that don't. Does that make sense?

Joe
  • 11
  • 1
  • Yes you always need to protect user provided passwords, not for your own sake (if you have additional protection) but for the sake of the users reusing passwords and for the potential image loss if you are the source of leaked password lists. – eckes Aug 17 '17 at 00:11

1 Answers1

2

You do need a proper password hash (slow and salted — iterating is one way to make it slow). It doesn't matter that the user has a second authentication factor such as a certificate. Hashing the password doesn't protect against the same threat.

Using a second authentication factor protects against someone guessing the user's password on your site, or obtaining the password by snooping on communication, by shoulder surfing, with a keylogger, etc. The protected asset is access to the user's account. For that purpose, the way your server stores the password is irrelevant.

A proper password hash protects the password against an attacker who gets access to the password database on your server (or a backup). The protected asset is the password value, which the user may have used on other sites. For that purpose, how the user authenticates on your site is irrelevant. Your server could even store a password hash that it doesn't use to authenticate the user (for example, if you're running a proxy authentication service), and it would still need to store the password securely.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • `it would still need to store the password securely.` Precisely. No portion of an authentication system should be implemented in a less than "proper" way. If you can store a password properly with a salted hash, it should be, no matter the other authentication factors. That being said, SHA hashes aren't specifically designed for passwords, even with salt. **bcrypt**, for example, with a use-case considered work factor (such as a minimum of 8) is a better alternative for password hashing along with PBKDF2 and others. – Nick Bedford Aug 17 '17 at 04:05
  • @NickBedford SHA is *not suitable* for use as a password hash. You need a salted *and slow* hash. PBKDF2 is a slow hash that uses SHA as a building block: it basically calls SHA repeatedly, a large number of times. Bcrypt is a slow hash with a different design, arguably better (because it uses more memory, which makes dedicated cracking machines more expensive), but using an iterated hash scheme such as PBKDF2 or the Unix “SHA” password “encryption” schemes (which are actually hashes and not passwords, based on a design that's similar to PBKDF2) isn't irresponsible. – Gilles 'SO- stop being evil' Aug 17 '17 at 08:52