On Jul 30, 2009, at 10:26 PM, Bottiger wrote: > >> That may not be a good idea, I think. That makes your password >> longer but with a possible cryptographic weakness because it's >> following a known generation rule (being formed by a string >> repeated 3 times). > > The primary concern is a precomputed rainbow hash table. > > Anything related to password generation strength depends on the > person's original password and even a random salt does not help, > because if the database is compromised, then the attack knows which > salt to generate hashes for. Therefore there really isn't anything > wrong with just doubling or tripling the password as a salt. > > In fact, many websites such as Reddit (which I examined the source > code) does this.
Still a bad idea. A rainbow table is basically a precomputed dictionary attack. The size of the dictionary is a function of the number of distinct passwords that we're trying to guess. Dictionary attacks work for short passwords, but are impractical against longer passwords. A password using letters, numbers and a few special characters carries in excess of 6 bits of information per character. 10 bytes of password plus 10 bytes of random salt gives us 120 bits total, for a dictionary space of 2^120 hashes. Precomputing the possible hashes for each base password requires a table of 2^60 hashes *per password*. On the other hand, a hash of a single deterministic transform of each password requires one hash per password. That's the point of salt. And no, I'm not concerned about spending a few extra bytes per password. I just paid $90 for a terabyte drive; that'll store plenty of password hashes, even if we "waste" a few bytes each making them more secure. > > On Jul 30, 9:51 pm, Francisco Gama <francisco....@gmail.com> wrote: >> On Jul 31, 5:16 am, Bottiger <bottig...@gmail.com> wrote: >> >>> As long as the salt is different for every password, it pretty much >>> makes it infeasible for someone to create a large enough rainbow >>> hash >>> table attack. >> >>> The Unix salt of 12 random bytes is ok, but comes at the cost of >>> extra >>> storage and pretty much the same benefit. To put a larger barrier on >>> computational speed, you could double or triple the original >>> password >>> before putting it through the hash. >> >> That may not be a good idea, I think. That makes your password longer >> but with a possible cryptographic weakness because it's following a >> known generation rule (being formed by a string repeated 3 times). >> That makes the diversity of possible passwords much smaller which >> isn't a good password policy. >> >> Besides, the complexity is the same (which is close to say that the >> computational speed is also close) and an attacker would need the >> same >> number of attempts to break the password by brute force because all >> he >> had to for each attempt X, the attempt XXX. He doesn't need to try X >> or XX. >> >>> On Jul 30, 8:38 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >> >>>> On Jul 30, 2009, at 8:30 PM, Bottiger wrote: >> >>>>> I know you have the mantra of not breaking backwards >>>>> compatibility, >>>>> but it is a pretty bad idea to have unsalted MD5 passwords. >> >>>>> For example, let's say your password is "massimo". The MD5 hash of >>>>> that happens to be "8cac5ac44b51f182143a43c4cdb6c4ac". >> >>>>> Even forgetting rainbow tables, you can simply do a search for >>>>> it on >>>>> Google and you have 10+ pages telling you that it is the hash for >>>>> "massimo". >> >>>> How about a new validator that does the right thing, and >>>> deprecating >>>> CRYPT? >> >>>> I'd prefer some less-predictable salt than the suggestion below, >>>> though. How about the old Unix passwd trick of choosing a some >>>> random >>>> salt, and appending the salt in plaintext to the hash? >> >>>>> http://www.google.com/search?q=8cac5ac44b51f182143a43c4cdb6c4ac >> >>>>> On Jul 30, 8:10 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: >>>>>> We cannot break backward compatibility. People should specify a >>>>>> key >>>>>> and use the HMAC+SHA512 anyway. >> >>>>>> Massimo >> >>>>>> On Jul 30, 9:49 pm, Bottiger <bottig...@gmail.com> wrote: >> >>>>>>> The CRYPT validator is unsecure because it uses unsalted MD5. >> >>>>>>> There are public rainbow tables that have unsalted MD5 passwords >>>>>>> of up >>>>>>> to 10 characters long including symbols. >> >>>>>>> I highly recommend that if no "key" is specified, that CRYPT >>>>>>> will >>>>>>> automatically salt the password based on a substring of the >>>>>>> password >>>>>>> itself. For example: >> >>>>>>> password = "secretpass" >>>>>>> hash = md5(password+password[-1]) >> >>>>>>> This will of course break backward compatibility, but this is >>>>>>> a real >>>>>>> security vulnerability. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
