[OWASP_PHPSEC] Second Library - Password Management

Abbas Naderi abiusx at owasp.org
Tue May 28 16:48:47 UTC 2013


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/015b0536/attachment.html>


More information about the OWASP_PHP_Security_Project mailing list