On Aug 2, 2009, at 11:26 AM, mdipierro wrote: > > On Aug 2, 1:11 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Jul 31, 2009, at 11:11 PM, Bottiger wrote: >> >> >> >>> I wrote before that I would not say anything about this anymore, but >>> having this thread pop up multiple times presented itself as a >>> persistent itch. >> >>> First of all I would like to apologize if I came off before as a >>> little abrasive. Second of all, I will not disagree that overall, >>> using a random salt is theoretically more secure. However, the other >>> method does not change the status quo much (no new db columns >>> something I believe Massimo values), at the cost of non-maximal >>> security. >> >> I think that any of the enhancements that have been floated would be >> an improvement over a straight MD5 hash. In order of (my intuitive >> sense of) increasing robustness: >> >> 1. Append a longish static string of salt to the password before >> invoking MD5. I think this is what you've been suggesting, and I >> agree >> that it's a significant improvement that would ensure that the >> resulting hashes would not be in standard rainbow tables. The salt >> could include nulls or other nonprintable characters that would not >> be >> used in dictionary attacks. > > this is useful ONLY if the developer can set the salt. hence one has > to pass the salt to CRYPT. hence why is this better than just passing > a key ans using HMAC (what web2py does)?
We could have a default salt of sufficient length (or content) to guarantee that the resulting passcode would not be in the existing dictionary attacks or rainbow tables. The developer needn't set it (though it'd be trivial to allow the developer to override it). > >> 2. Append the user's email address to the password before hashing, >> perhaps with some other static salt. This would have the additional >> advantage that the same password wouldn't hash to the same value for >> different users. Disadvantage: application logic would have to rehash >> the password if the user changed their email address, and with email >> verification that could be a little tricky. But doable. > > No because if the user changed email, the password would become > invalid. That's what I said above, starting at "Disadvantage". > >> 3. Append random salt to the password before hashing, and append the >> same salt to the hash. This doesn't require a new database field. It >> does make the password field longer by a few bytes, but I don't see >> that as a significant objection (after all, we don't object to the >> SHA512 hash length). This shares the advantages of (2) but doesn't >> rely on a second database field and isn't affected by user profile >> changes. > > This still needs to pass the salt. Then pass the key and use hmac. No, in this case the salt is generated by something like random.randint. The developer need pass nothing. > >> An application developer can realize the advantages of (1) and then >> some by supplying a key and getting a SHA HMAC, and not worrying too >> much about key secrecy. The advantage of (1) would be to make the >> default hash method more secure than a straight MD5, which is >> significant. > > I am not suggesting anybody should use MD5. I am just saying people > should just do > > key="my secret key" > ....requires=CRYPT(key=key) Then let's make this the default, with a default key. The path of least resistance ought to be the secure path, not the insecure one. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
