It has to do with the fact that the defender is obligated to pay the cost of the AES every time (because he follows the rules of the algorithm by definition). But the attacker is free to bend the rules however he can and one thing he can do is perform the AES once on the entire data file, a negligible amount of computation.
So even though AES is an identity transformation, it makes the function more costly for the defender than for the attacker. Wncrypting one's database may be an acceptable tradeoff for other reasons, but when we're considering the work factor for cracking passwords this is worse.
Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.
>Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.
I agree, and I don't think AES (or any easily invertible function) should be used to increase the work factor.
We have been arguing past each other. I was responding to a post that said ~'if you compose two functions and the second function is insecure, than the composition is insecure'. While such a statement is correct for compression/hash functions, it does not hold for permutations.
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? Assuming that keeping a key secret is much easier than keeping a bunch of hashes secret, which is a fair assumption, shouldn't such a method increase the security of the system?
> 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).
This is the part that I think is subtly invalid. Coincidentally, I was having this mailing list discussion the other day: http://lists.randombit.net/pipermail/cryptography/2012-May/0...
It has to do with the fact that the defender is obligated to pay the cost of the AES every time (because he follows the rules of the algorithm by definition). But the attacker is free to bend the rules however he can and one thing he can do is perform the AES once on the entire data file, a negligible amount of computation.
So even though AES is an identity transformation, it makes the function more costly for the defender than for the attacker. Wncrypting one's database may be an acceptable tradeoff for other reasons, but when we're considering the work factor for cracking passwords this is worse.
Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.