On Friday 31 July 2009 10:32:23 Bottiger wrote: > > 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. > > I don't think you are understanding the situation, and I am getting a > bit tired of repeating myself. Cope with it. It's not always obvious to someone else what is obvious to you.
> The problem with unsalted passwords is when the database is > compromised. When it is compromised, the salt becomes publicly > available, and having a totally random salt is not going to be a big > difference between a semi-random salt. To an attacker, this is what > they see: > > My suggestion: password + x characters recorded in the db (as the > password itself) > Your suggestion: password + x characters recorded in the db (in > another field) > > To crack these passwords they still only need to calculate password+x > characters stored in the db regardless of how random your salt is. The > only thing that really matters is that it is reasonably different for > each password, and that no one else has made a rainbow table for a > salt that you happened to choose. Hey, don't you think that both approaches have good and bad sides? What if you combine them? double or triple the password (cutting off some letters if you wish or even shuffle them always in same manner), add a random salt and store result, along with the salt in the db? Put a new validator there that will use that algo, deprecate old one (but keep it around forever for sake of backward-compartibility). > On Jul 30, 10:50 pm, Jonathan Lundell <jlund...@pobox.com> wrote: > > 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. > > -- Sincerely yours Alexey Nezhdanov --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
