We can probably make a validator called CRYPT2() so we don't have to break backward compatibility. In my opinion though, this is a rather insecure default for a framework that bills itself as being very secure. I have seen many hacklogs where PHP frameworks were often compromised by sql injection -> unsalted md5 dump -> rainbow lookup -> attacker now accesses the entire server because the host used the same password on his website as the root account.
I think SHA512 with a static key would be ok, as I have yet to see any rainbow tables for that yet. But theoretically, having a different salt for each password would prevent any attackers from generating 1 table for all the passwords from a static salt. And with my method you wouldn't have to allocate additional storage to get the same effect. On Jul 31, 12:19 am, Fran <francisb...@googlemail.com> wrote: > On Jul 31, 4:10 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > We cannot break backward compatibility. People should specify a key > > and use the HMAC+SHA512 anyway. > > Currently the default auth_user table just has: > table[passfield].requires = [CRYPT()] > > So *all* instances should amend that, right? > > This should be in the scaffolding app & very clear in the > docs:http://web2py.com/examples/default/tools#authentication > new manual (chapter 8) > > F --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
