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. Now I will address the issues that seem to be the cause of much debate. 1. Attackers are only interested in 1 of the passwords. If you have observed hacklogs, you will see that the only password the hacker is interested in is the admin or root user. Why? Because it is the one that is most likely to be the same as the computer the website is hosted on. The hacker does not care about the other user passwords. He already has the entire database and can play with everyone else's accounts on the website. The only thing that could extract more value is the possible connection that the root/admin account may be the same as the host. (I can already hear you saying what if other people use the same password as their email, but this doesn't happen as often as you think and usually disposable or fake emails are used). So what is the consequence of this? That hackers will use their publicly precomputed unsalted rainbow tables to hack 1 account. Therefore we should consider the case where a rainbow table attacks 1 password, not a collection. 2. Attackers will specifically target Web2Py's deterministic algorithm with a custom rainbow table. This is a possibility, but it is not a big one. First of all, even with md5, generating tables is not something the average script kiddie can do. It is only with the recent growth of public distributed rainbow tables that you are seeing much more of these kinds of attacks. Even a website as popular as Reddit has been using a salt dependent on the password, and so far there have not seen any rainbow tables specifically for their hash variant. For script kiddies, lack of public rainbow tables for your variant will lock them out. For serious hackers, they only care about the admin account anyway. And they have the resources to mount a single salted attack on it, which means that a randomized salt is equivalent to a deterministic salt. So what is the consequence of this? That the script kiddies that would be interested in compromising the other accounts besides root are unable to do so, and the serious hackers would not waste their time on a single variant, and would instead attempt to crack the admin/root account. When you consider these circumstances, it makes sense to consider that the deterministic salt is equivalent to a random salt. The purpose of the deterministic salt that I proposed was to eliminate the weakness of a public rainbow table attack without the need to alter the schema of the table or specifying a specific key.This was a vast improvement over the current default without a change in the database. I was also going to suggest using the user.id as a salt as someone else mentioned, but that may depend on several possible problems such as people changing their id, or id's being deleted, and then having the database reinserted with different ids. On Jul 31, 9:09 pm, Francisco Gama <francisco....@gmail.com> wrote: > On Jul 31, 6:26 am, Bottiger <bottig...@gmail.com> 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. > > I know, but a brute force attack becomes more achievable using a rule > like that because you are introducing a lot of restrictions to the > possible passwords domain. > I give you an example, if you have a 32 bytes field for the password > and you generate passwords according to that rule, the attacker will > know in advance that he doesn't need to try passwords with a length > higher than 32 / 3 bytes, he also doesn't need to try passwords that > are smaller than the minimum allowed size by the application * 3 and > he can reject in advance all passwords that aren't formed by a > triplication of a substring. > > I would say that for serious applications just use other algorithm > such as SHA-1. > > > 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. > > > On Jul 30, 9:51 pm, Francisco Gama <francisco....@gmail.com> wrote: > > > > On Jul 31, 5:16 am, Bottiger <bottig...@gmail.com> 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 <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 -~----------~----~----~----~------~----~------~--~---
