Of course, hashing a password, per se, doesn't really make it any stronger. And doing things like using a salt don't do much if the concern is simple trial-and-error cracking of a single encrypted message (unless you're relying on "security by obscurity"). Salting does help prevent known plaintext attacks and signature spoofing, but those are not likely to be problems in low-volume messaging. Iterating on an expensive hash can help discourage the trial-and-error cracking attack, but it can add considerable overhead to the normal path, and simply increasing the length of a weak password would be far more effective.
On May 10, 5:34 pm, Bob Kerns <[email protected]> wrote: > The fundamental problem with starting with a human-managed password is that > there is not a lot of entropy -- the possible values are not distributed > over a huge range, compared to what an attacker could try with > trial-and-error. > > So just doing SHA1 or SHA256 for that matter, is not sufficient for a strong > key generation algorithm. > > The first thing you need to address are dictionary attacks, where the > attacker can pre-compute a large dictionary of keys from likely passwords. > Here, you can inject randomness into the process. What you do is to start > with a large random number, termed a 'salt'. This is not a secret -- you'll > save it away in cleartext somehow, and then combine it with the user's > password. While the attacker could afford to build a dictionary of keys > based on passwords, a dictionary of possible salt values + passwords would > be vastly larger. > > The other thing you need to do is to protect against trial-and-error > attacks. To do this, what you do is make it expensive enough to compute the > key that an attacker simply couldn't try enough to get anywhere. The usual > way of doing this is to iterate some expensive function -- such as SHA1. > More precisely, you iterate this: > > hash = f(hash) > > where f is some function that is expensive, and does not collapse the space > of possible values into some smaller set. One way to accomplish this would > be: > f(hash) = hash <xor> sha1(hash). > > I went with SHA1 above, because I want to tie this to PBKDF2, which Nikolay > referenced. > > What I outline above is roughly what PBKDF2 does for you. You can read the > full details in rfc2898 <http://tools.ietf.org/html/rfc2898>, and I > encourage you to do so. I did skip over a lot of detail to focus on the > motivation and approach. > > So there are basically two parameters -- the salt (selected randomly) and > the iteration count (selected to make it expensive but not too expensive). > iOS4 uses I believe something like 10000 iterations. Blackberry used 1, and > was seriously pwned as a result. > > Together, these compensate for the narrow range of human-generated > passwords. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
