I don't assume my system is invulnerable.. just as you should not assume bcrypt is invulnerable (its at least as vulnerable as everything else from the perspective of brute forcing/attacking at the login form).
I do however take reasonable steps to reduce the risk of my system being attacked.... rather than finding some evangalistic link and regurgitating what is written by said evangelist as if its some kind of enormous threat to security if you don't follow what is said...your evidence is not backed up - you have not yet cracked the hashed password provided to you in under 8 minutes despite how "easy" you claim it to be.... steps I take: 1) my production DB server is only accessible from the IP address of my application server 2) my production DB server and my production application server are 2 separate physical machines 3) my production DB server and my production application server use different usernames and passwords (however, admitted weakness is the fact that the db username and password are revealed in the config file which is accessible if you have breached the prod app server) 4) login forms will force the user to pass a reCAPTCHA if the number of failed logon attempts is greater than 3. An attempted brute force at this point is far more likely than an attack directly at the database, and this will significantly slow down any attacker. 5) where possible, login forms use SSL, to mitigate MITM attacks 6) passwords are required to be a minimum of 8 characters long, contain both upper and lowercase letters, at least 1 number and at least 1 letter, as well as at least one symbol. 7) server logs are routinely checked for suspicious activity, and suspect IP ranges are blocked. all of this is what i would call REASONABLE - add that to randomly generated salt for each application, use of the security component, and I would say you've got a pretty solid defense.... and no, the overhead of 0.3 seconds at log-in time is not acceptable. an overhead of an additional 0.01 seconds is not acceptable. Nor is the increased computational overhead acceptable...nore are the risks of adding a security hole by hacking together a solution on the framework acceptable....at least not to me or my clients/users. On Wed, Sep 14, 2011 at 12:24 PM, Chris Cinelli < [email protected]> wrote: > Again, if you assume that your system is invulnerable, why complicating > your life using hashed passwords in the database, then? Put them in DB in > clear. > I understand that getting the DB and the salt may not be trivial. However > every once in a while vulnerabilities are discovered and bad guys can be > able to access your server. By the time a patch for the vulnerability is > applied, somebody may have your DB and code. If the passwords can be > inferred easily from it, the adversary has access to your data in your > system FOREVER. Probably nobody is interested in getting control of your > system, or at least nobody with the necessary skills. But I prefer not to > take a chance on mine. > > If you spent time to look how the bcrypt works and what I wrote in the > previous emails, you would have found that, because how bcrypt works, you > cannot just plug it in the hashPasswords. But thank you for the suggestion. > > We made it work in CakePHP 2.0RC1 but it required us to write something > "hacky". If we have time we will try to submit a patch to make it clean but > I am not sure we have enough knowledge of Cake to make it general enough. > > Best, > Chris > > On Tue, Sep 13, 2011 at 6:33 PM, Greg Skerman <[email protected]> wrote: > >> The inference is that every cake application is magically vulnerable to an >> attack predicated on ridiculously weak passwords and the highly unlikely >> occurance that the attacker has both the salt and unfettered access to the >> database. >> >> If you are so convinced, couldn't you override >> AuthComponent::hashPasswords() though? >> >> from the book: >> >> If you want to use different password hashing logic beyond md5/sha1 with >> the application salt, you will need to override the standard hashPassword >> mechanism - You may need to do this if for example you have an existing >> database that previously used a hashing scheme without a salt. To do this, >> create the method >> hashPasswords<http://book.cakephp.org/view/1259/hashPasswords>in the class >> you want to be responsible for hashing your passwords (usually >> the User model) and set >> authenticate<http://book.cakephp.org/view/1278/authenticate>to the object >> you're authenticating against (usually this is User) >> >> I've never seen a need to do it, but it would appear it exists for exactly >> this reason - for building hashing logic that differs from the core logic >> shipped with the auth component. >> >> >> >> >> On Wed, Sep 14, 2011 at 10:47 AM, Chris Cinelli < >> [email protected]> wrote: >> >>> Or maybe, Paypal is using bcrypt. :-P >>> >>> Yes, of course you need the user table in the DB, but if it is your >>> argument and you feel strong on how difficult is to access you DB, why don't >>> you store the passwords in clear in your DB? >>> I am not saying that it is easy to do, but in case it happen (see RockYou >>> story for example), the attacker can access any account on the system, and >>> probably more than that since a few user reuse the same password on multiple >>> websites. >>> >>> Regarding "your bcrypt is just as vulnerable to a plain jane dictionary >>> attack as anything else." It is not mine, unfortunately. But actually the >>> speed necessary to calculate an hash IS a factor against brute forcing. >>> Because if it takes a microsecond or instead nearly one second to calculate >>> the hash make a huge difference. While ,according to the link I posted, it >>> takes 40 sec to crack a SHA1 hash of 6 letter password, it would take >>> 40*1,000,000 sec to crack a bcrypt hash that is more than a year. In the >>> case posted in my previous message is 8min with SHA1 vs more than 12 years >>> with bcrypt. >>> Another interesting property of bcrypt is that given the same password >>> the hash generated is (practically) always different so you cannot >>> pre-calculate the hash values. Trying a dictionary attack checking hundred >>> of millions of terms is just unpractical too. >>> That is actually the point, if it takes 8 minutes or even a day, an >>> attacker may actually do that. If it takes year, he will probably desist and >>> try to get access of another system that use SHA1 like someone out there :-P >>> >>> This thread is going longer than necessary. The point is: if somebody >>> wants to use SHA1 can freely do it. It would be nice that cake would not >>> make the assumption that the password is a traditional hash and insert the >>> plug for a verify_password function instead of the current password() >>> function that return an hash. >>> >>> Best, >>> Chris >>> >>> On Tue, Sep 13, 2011 at 4:46 PM, Greg Skerman <[email protected]>wrote: >>> >>>> >>>> >>>> On Wed, Sep 14, 2011 at 8:33 AM, Chris Cinelli < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> According to: http://research.microsoft.com/pubs/74164/www2007.pdf *~20% >>>>> of Fidelity, ~20% of NY Times, ~15% of Paypal* have a password with >>>>> bit strength of 30 or less. According to that study, this mean that If I >>>>> know the hash and salt, you need to try just 2^30 total combinations to >>>>> find >>>>> the password of 45% of Paypal users. Using a ATI HD 5970 (that you can >>>>> find >>>>> at $499 at Buy.com and http://www.golubev.com/hashgpu.htm you can try >>>>> 2,300,000 SHA1 hashes a second. >>>>> >>>>> >>>>> >>>> No you can't - you'd need 45% of PayPal User's usernames... And the db >>>> table of passwords to check against...neither of which is trivial to get. >>>> >>>> if it was this easy, everyone would have 45% of paypal user's >>>> passwords.... >>>> >>>> -- >>>> Our newest site for the community: CakePHP Video Tutorials >>>> http://tv.cakephp.org >>>> Check out the new CakePHP Questions site http://ask.cakephp.org and >>>> help others with their CakePHP related questions. >>>> >>>> >>>> To unsubscribe from this group, send email to >>>> [email protected] For more options, visit this >>>> group at http://groups.google.com/group/cake-php >>>> >>> >>> -- >>> Our newest site for the community: CakePHP Video Tutorials >>> http://tv.cakephp.org >>> Check out the new CakePHP Questions site http://ask.cakephp.org and help >>> others with their CakePHP related questions. >>> >>> >>> To unsubscribe from this group, send email to >>> [email protected] For more options, visit this group >>> at http://groups.google.com/group/cake-php >>> >> >> -- >> Our newest site for the community: CakePHP Video Tutorials >> http://tv.cakephp.org >> Check out the new CakePHP Questions site http://ask.cakephp.org and help >> others with their CakePHP related questions. >> >> >> To unsubscribe from this group, send email to >> [email protected] For more options, visit this group >> at http://groups.google.com/group/cake-php >> > > -- > Our newest site for the community: CakePHP Video Tutorials > http://tv.cakephp.org > Check out the new CakePHP Questions site http://ask.cakephp.org and help > others with their CakePHP related questions. > > > To unsubscribe from this group, send email to > [email protected] For more options, visit this group > at http://groups.google.com/group/cake-php > -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php
