As a serious aside...
if the Auth component/hashPasswords won't do it for you, could you not
subclass the auth component:
BcryptAuthComponent extends AuthComponent {
}
and replace the 'offending' bits of the code so it *does* work for you?
again, never tried (never saw the need) but if there is a pressing need to
do this for whatever reason, and the AuthComponent doesn't let you do it -
surely this is a way out?
On Wed, Sep 14, 2011 at 1:25 PM, Greg Skerman <[email protected]> wrote:
> 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
