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
