On Aug 1, 2009, at 4:03 AM, mdipierro wrote: > Problems: > a) You still need to pass a key to CRYPT > b) It will break backward compatibility unless data is converted > c) We cannot easily convert the data without human intervention.
We could, actually, but always encoding and checking with password +salt, but checking with plain password if password+salt failed, and (possibly) updating the hash if that happened. That way you'd retain backward compatibility, but update to a salted hash either on the next successful login, or the next time a password was created. > > The problem with collisions is not really important for short strings > like passwords. So SHA512 in itself is not worse than MD5 in this > case. The difference is HMAC or not HMAC. In fact, if attacker gets > access to the databases in the non-HMAC case he may be able to derive > passwords using a look-up table. In the HMAC case this will be more > difficult. Since to use HMAC you need to hardcode an app password in > the app and pass it to CRYPT I do not see why any change in the code > would be necessary. Mainly to make the default case more secure without forcing the developer to take explicit action. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
