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. 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. 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. 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. > > 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. I'm not sure I accept the premise. This depends a lot on the specific application and what individual users might be storing. Sure, an administrative password could be more valuable in the general case. > > 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. I'm definitely in favor of static salt as better than nothing. But if you're going to bother, I don't really see the downside of random salt. > > > 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 -~----------~----~----~----~------~----~------~--~---
