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. 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 -~----------~----~----~----~------~----~------~--~---
