> Do you agree that keys or peppers decrease the risk of passwords being revealed if the key or pepper can remain secret from the attacker?
I'm not familiar with this term 'pepper'. I take it to be a key with which you encrypt a password has as in your construction?
> Assuming that keeping a key secret is much easier than keeping a bunch of hashes secret, which is a fair assumption,
I don't know that it's such a fair assumption. For example, where does the server software get the key when it boots? From the hard drive? Is it something that is chosen or typed in by admins? If so, how do you ensure this key isn't itself simply derived from a weak password? If it's a password, how likely is it to be the same as the root login password or master database password? If the app developer re-uses this key or password in multiple contexts it's an additional exposure.
> shouldn't such a method increase the security of the system?
I think it could help and might even be a good idea overall.
That said, I don't think we should consider it an intrinsic part of password hashing security because:
a) It might help some with pure SQL injection exploit scenarios but anything beyond that it probably won't help at all. So any security benefit it brings is very hard to quantify.
b) It could apply equally to any sensitive database field that didn't require join capabilities.
c) It imposes a work factor to the defender which can be bypassed by the attacker.
I think the most secure method would be to store a random string in the persistant memory of a hardware dedicated device that performs the encryption on your behalf (like a smart card or trusted computing module). If that is not possible you could still put the key inside the hash program and give the app only execute privileges for that program (the key is safe unless the attackers get root).
a). If it protects against a very common attack or attacker why not do it. Security should be layered.
b). agreed
c). The work factor of a single AES encryption is negligible for both the attacker and the defender and can be ignored. Furthermore it can be removed entirely if you hash both the input and the output as I proposed in a previous message, SHA( AES(K, SHA(password) ) ). Now the attacker has to run AES for each try as well (but it doesn't matter since any reasonable work factor will be orders of magnitude larger than a single AES operation).
I'm not familiar with this term 'pepper'. I take it to be a key with which you encrypt a password has as in your construction?
> Assuming that keeping a key secret is much easier than keeping a bunch of hashes secret, which is a fair assumption,
I don't know that it's such a fair assumption. For example, where does the server software get the key when it boots? From the hard drive? Is it something that is chosen or typed in by admins? If so, how do you ensure this key isn't itself simply derived from a weak password? If it's a password, how likely is it to be the same as the root login password or master database password? If the app developer re-uses this key or password in multiple contexts it's an additional exposure.
> shouldn't such a method increase the security of the system?
I think it could help and might even be a good idea overall.
That said, I don't think we should consider it an intrinsic part of password hashing security because:
a) It might help some with pure SQL injection exploit scenarios but anything beyond that it probably won't help at all. So any security benefit it brings is very hard to quantify.
b) It could apply equally to any sensitive database field that didn't require join capabilities.
c) It imposes a work factor to the defender which can be bypassed by the attacker.