On Jul 31, 2009, at 9:36 AM, Julio wrote: > Both methods are really flawed and we all know it, adding a "random" > flavor to the salt (and storing it somewhere) is no more difficult to > "crack" than salting a password with the first, third and fifth > letters of the original password for example (or the way I am doing it > for that matter), > > I believe we all know that MD5 is not the best hashing algorithm, > since it only supports 128-bit digest length, the problem is that we > are not *encrypting* our passwords, but rather hashing them, python > does not provide afaik a good encryption implementation (without the > use of 3rd parties), and implementing an encrypting algorithm will > surely render web2py incompatible with "earlier" versions. > > It does not really matter what we "salt" our hashes with, they will > always be breakable, period. Now, assuming that we'll continue using > MD5(unsalted_passwd), the *truly* only way to "defeat" rainbow table > attacks is simple and does not involve breaking backwards > compatibility: Use strong passwords, if your password is [myname] > [myDOB], you *deserve* to be hacked (I'm kidding of course).
We should be clear about which problem(s) we're trying to solve. 1. Any really secure mechanism is going to require a strong password, and probably more than that, such as a two-factor method. But we know that we can't impose a strong-password requirement on every application. 2. Weak passwords are subject to a blind, brute-force dictionary attack. Nothing we do with the hash is going to help this; the attacker never has to compute a hash. We can mitigate it by rate- limiting password attempts, and we should probably do that, perhaps by adding a timestamp to the user table that remembers the last password attempt, and imposing a delay before attempting another validation, or by locking out a user after some number of failed attempts. 3. If the attacker has access to the user table (user names plus hashed passwords), then he can mount an offline brute force attack. How practical this is depends on how big the attacker's dictionary is, and of course how likely it is that a user has chosen a password weak enough to be in the dictionary. Note that an HMAC defends against this attack by using a secret key, which acts effectively as "secret salt". The problem with this is that, if you assume that you can't keep the user table secret, then how can you assume that you can keep the HMAC key secret? Still, it's something. 4. Rainbow tables are a special case (3) above. The point of this attack is that, once the table is computed, it's *very fast* to determine whether a given hashed password is in the table. The reason that random salt is a defense against this attack is that it makes the rainbow table impractically large. Don't confuse a rainbow-table attack with a brute-force attack against a known hashed password (3 above). 5. Secret salt is even better, but then we're back to the question of how to keep the salt secret when we're assuming that we can't keep the hashes secret. Here's another test you can apply to salting systems. If two users choose the same (plaintext) password, what are the chances that they'll end up with the same hash? With simple md5, with or without a deterministic transformation of the plaintext, the hashes will always be the same. With random salt, even if the salt is not secret, the chance of a collision can be made arbitrarily small. See the Wikipedia entries on salt: http://en.wikipedia.org/wiki/Salt_(cryptography) and rainbow tables: http://en.wikipedia.org/wiki/Rainbow_table --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
