Every time I read something from OWASP, it has a bunch of glaring deficiencies, and appears to be an uneditable wiki. This time around:
Authentication_Cheat_Sheet: password rules which only apply to US-ASCII. That means people with non-US keyboards may not even be able to set a password which meet the rules (eg. Θ and ẞ are upper case, but does not count as upper case in their suggested rules).
Password_Storage_Cheat_Sheet: misses the critical step of unicode canonicalisation and encoding before feeding the password into the slow one-way function (which invariably take an octet string, not textual strings). If you fail to do this, your system will spuriously reject correct passwords if the user logs in via different devices or input methods.
Password_Storage_Cheat_Sheet: '32-bit or 64b' length salt is certainly too short to be called cryptographically strong. Particularly, a 32-bit salt is not enough to avoid leaking password equality with good probability between users once you get past the birthday bound.
Password_Storage_Cheat_Sheet: implies that the caller is responsible for prepending the salt to the credential before inputting it into the slow one-way function. That's not how PBKDF2, scrypt or bcrypt work.
Your assertion about the salt is wrong. That's not what a salt is designed to prevent. A salt is to prevent pregenerated tables from being meaningful, therefore 32-64bit is plenty.
'good probability' is a little dramatic too. The birthday paradox would only apply if every user had the same password to begin with. With 32 bits, you would need about 77000 users with the exact same password to get to 50% probability of two having the same salt/hash. 2000 users with the same password is 0.1% probability of two being the same.
If you are concerned about equalities because you have thousands of users with the same password, input the username into the hash generation function as well. Don't waste space with needlessly large salts.
I agree with you, in particular about the "password storage" stuff. OWASP has a particularly poor history of engaging with cryptography, and, because (I think) of the personalities involved, tend towards a "teach the controversy" approach anytime they're corrected.
As one of the original authors of clasp, I agree with the poster. We can do so much better. But it's important to realize these things move slow for a variety of reasons. Patches welcome.
Depending on the language and regex interpreter options, this isn't as strict as it could be since it might accept unicode numbers. For the paranoid, this would be better:
^[0-9]{5}(-[0-9]{4})?$
Edit: And security issues aside, there's really no need for a capturing group on the last four digits, thus it could be:
How about chars in zip codes (afaik GB has chars in zip codes)?
Input validation is usually a UX fail because there will be for sure one thing you miss (traditional example: email address validation). Zip codes I'd rather don't check at all or check against a list of valid zip codes if really necessary.
Nope not really. Probably only tards who can't seem to see that most of the successful web runs on PHP, not on their Brogrammer flavour-of-the-week language or framework.
[+] [-] ctz|12 years ago|reply
Authentication_Cheat_Sheet: password rules which only apply to US-ASCII. That means people with non-US keyboards may not even be able to set a password which meet the rules (eg. Θ and ẞ are upper case, but does not count as upper case in their suggested rules).
Password_Storage_Cheat_Sheet: misses the critical step of unicode canonicalisation and encoding before feeding the password into the slow one-way function (which invariably take an octet string, not textual strings). If you fail to do this, your system will spuriously reject correct passwords if the user logs in via different devices or input methods.
Password_Storage_Cheat_Sheet: '32-bit or 64b' length salt is certainly too short to be called cryptographically strong. Particularly, a 32-bit salt is not enough to avoid leaking password equality with good probability between users once you get past the birthday bound.
Password_Storage_Cheat_Sheet: implies that the caller is responsible for prepending the salt to the credential before inputting it into the slow one-way function. That's not how PBKDF2, scrypt or bcrypt work.
[+] [-] hueving|12 years ago|reply
'good probability' is a little dramatic too. The birthday paradox would only apply if every user had the same password to begin with. With 32 bits, you would need about 77000 users with the exact same password to get to 50% probability of two having the same salt/hash. 2000 users with the same password is 0.1% probability of two being the same.
If you are concerned about equalities because you have thousands of users with the same password, input the username into the hash generation function as well. Don't waste space with needlessly large salts.
[+] [-] tptacek|12 years ago|reply
[+] [-] ams6110|12 years ago|reply
[+] [-] raesene2|12 years ago|reply
[+] [-] alexnewman|12 years ago|reply
[+] [-] logn|12 years ago|reply
[+] [-] mweibel|12 years ago|reply
Input validation is usually a UX fail because there will be for sure one thing you miss (traditional example: email address validation). Zip codes I'd rather don't check at all or check against a list of valid zip codes if really necessary.
[+] [-] davedx|12 years ago|reply
[+] [-] wglb|12 years ago|reply
[+] [-] tharri|12 years ago|reply
[+] [-] ADFASFGADA|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] Fasebook|12 years ago|reply