Ed W wrote:
- Generate an initial SHA256 hash out of the password+salt.
- Re-hash the initial SHA256 hash many thousands of times.
As an aside you should do some research to determine if the second of these steps adds any value. I don't believe that there is a known way to reverse an SHA256 hash, and if one is discovered it's not immediately obvious that the technique would not break the case of it being applied multiple times...
The value it adds is that it slows down a brute force attackers by reducing the number of keys they can try per second (modest systems can try ~65,000 keys per second). So by re-encrypting the keys (say 65,000 times) reduces the number of keys an attacker can try per second from about 65,000/sec to 1/sec.
<... looks for the article ...>
Found it:
http://en.wikipedia.org/wiki/Key_strengthening
Also the keyspace of a password with say 8 alphanumeric chars is very much smaller than an SHA256 space, so you have a big bruteforce issue already
I will be the first to acknowledge that my encryption scheme is probably a healthy way into "overkill". As it is, the salt is a 32-byte string of alternating mixed-case letters, numbers and other characters (like space, '/', '\', '!', etc...).
The reason for the strength is that I use the underlying password scheme for multiple projects, some of which contain medical and financial information. Dovecot itself isn't such a big concern, but I like to standardize.
Basically it's not immediately obvious that step 2 adds any or at least significant value. Perhaps instead use a larger salt?
It's just to slow down brute force attacks and to help reduce the usefulness of rainbow tables that much further.
If you are using sql lookups then of course you can code all kinds of stuff as part of the lookup...
Good luck
Thanks kindly for your reply! I make *no* claims to being a security expert, so I quite welcome any feedback on my scheme. :)
Madi