[OWASP_PHPSEC] Second Library - Password Management

johanna curiel curiel johanna.curiel at owasp.org
Tue May 28 16:51:35 UTC 2013


Send it to me ;-)

Im into Riemann hypothesis!!!!

wow Abbas...

regards

Johanna


On Tue, May 28, 2013 at 12:48 PM, Abbas Naderi <abiusx at owasp.org> wrote:

> Hello Johanna, All,
> I do, but unfortunately they are of cryptographic nature and involve a lot
> of advanced math. I have had a long discussion with Jim Manico regarding
> this, and will ask him if its ok to share.
> Basically these things are true:
>
> 1. It doesn't matter how many "rounds" of hashing you do. Rounds only add
> coefficient complexity, not even polynomial complexity, and do not make any
> difference when things are cracked using Rainbow Tables (you definitely
> need to know exactly how Rainbow Tables work if you want to create a secure
> hashing library! If you can't find enough material online, ask me to type
> it here.)
>
> 2. The only difference between SHA and BCrypt is that, BCrypt is slower
> and its not standard. People think that if you use a slower mechanism,
> chances are you won't get hacked that easily. Its entirely false. The only
> thing that matters, is the bit-length of the algorithm, and to know that
> its not cracked yet (MD5 IS cracked in 2001, SHA1 has a found collision in
> 2007). For this case SHA-512 does fine (accoring to Birthday Paradox
> Theorem) and will do fine for a few years at least.
>
> 3. We definitely need salts. Adding salt (which is a known string) to a
> password, then hashing it, ensures a few things:
> I) Two users having the same password, wont have the same hash
> II) Existing rainbow tables, do not work on the salted passwords. One will
> need One Rainbow Table (a huge thing) for each salt to crack passwords.
>
> The 2nd law forces us to use dynamic salts, as one can create a rainbow
> table for a static salt (it will be worth doing this for say a million
> leaked password hashes!)
>
> Since dynamic salts are not long enough (salts require entropy), we will
> concatenate them with static salts. So we need Static (per application) and
> Dynamic (per password) salts.
>
> 4. We need to support backward compatibility, say for when SHA-512 (or
> anything else we use) is deemed insecure. We can not force all users to
> change their passwords once an algorithm is insecure (we need plaintext
> passwords to rehash them using a secure mechanism), so our system needs to
> support different methods and has to be backward compatible.
>
>
> On top of all that, plaintext passwrod security is of utmost importance,
> otherwise one would just run a dictionary attack.
>
> Thanks
> -Abbas
> On ۷ خرداد ۱۳۹۲, at ۲۱:۰۵, johanna curiel curiel <johanna.curiel at owasp.org>
> wrote:
>
> Abbas
>
> Would it be possible to let us know which concepts are wrong?
>
> I think would be nice if this is clarify for us. Do you have any docs on
> this?
>
> thanks
>
> Johanna
>
>
> On Tue, May 28, 2013 at 12:27 PM, Abbas Naderi <abiusx at owasp.org> wrote:
>
>> Abhishek,
>> Keep in mind that most of those libraries and posts take their ideas from
>> OWASP, and many of them has done it wrong. Do not trust them, you should do
>> something that is proven to be good, not something that is used most by the
>> industry. We have had talks in OWASP, and I can show you why most of those
>> idaes are wrong.
>> Thanks
>> -Abbas
>> On ۷ خرداد ۱۳۹۲, at ۱۵:۴۹, Abhishek Das <das.abhshk at gmail.com> wrote:
>>
>> Posting a few very useful links:
>>
>> http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt
>>
>> http://security.stackexchange.com/questions/4789/most-secure-password-hash-algorithms
>> http://en.wikipedia.org/wiki/SHA-2
>>
>> http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
>>
>> As of now, bcrypt seems like the most preferred hashing method, followed
>> closely by the SHA2 (multiple round) implementations.
>>
>> In addition to jframework, I am looking at the PHPass password hashing
>> framework as well to see how they've implemented stuff:
>> http://www.openwall.com/phpass/
>>  _______________________________________________
>> OWASP_PHP_Security_Project mailing list
>> OWASP_PHP_Security_Project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
>>
>>
>>
>> _______________________________________________
>> OWASP_PHP_Security_Project mailing list
>> OWASP_PHP_Security_Project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130528/d573b40e/attachment-0001.html>


More information about the OWASP_PHP_Security_Project mailing list