On Jul 30, 2009, at 11:47 PM, Jonathan Lundell wrote: > > On Jul 30, 2009, at 11:32 PM, 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. > > Well, that's up to you, of course. > >> >> The problem with unsalted passwords is when the database is > > (did you mean "salted passwords"?) > >> 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: > > BTW, I haven't seen a proposal for semi-random salt, only for > deterministic salt. I'm not actually sure what semi-random salt means. > >> >> 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. > > With a hash that's a deterministic function of the password (repeated, > inverted, whatever), a dictionary table needs only one entry per > plaintext original password. (How does the attacker know the function? > Download web2py and read the code.) Precompute one table and you've > broken *every password* in your dictionary. (It's no help against > truly strong passwords, but what we're trying to do here is to protect > middling passwords.) And you don't need access to the file of password > hashes.
Check that. You do need access, but given access you need to do essentially zero work to crack all the passwords in your precomputed dictionary. > > With random salt, on the other hand, even with access to the salted > hash, you have to do that much work to crack just one not-so-strong > password. > > The point of rainbow tables is to amortize the computation across the > entire password dictionary (with a bonus of not needing to see the > actual hashes). The point of salted hashes is to require the attacker > to use the same amount of computation to attack a single password, and > that only if he has accessed to the salted hash. > > Night and day. > > >> >> >> On Jul 30, 10:50 pm, Jonathan Lundell <[email protected]> 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 <[email protected]> wrote: >>>>> On Jul 31, 5:16 am, Bottiger <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
