OWASP Cheat Sheet Series
owasp.org
owasp.org
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.
'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.
Assume a 64-bit salt was chosen uniformly at random for each user. The probability that this cryptosystem is catastrophically broken (i.e. leaks password equality between users in just this population) is about 2^-23. That's not good -- usually cryptosystems are designed to have a probability of failure between 2^-80 and 2^-256. Now multiply that up for each population of users choosing the same password, and you're in trouble.
Adding in other user-unique data is definitely a good idea!
The failure cases are different though. Cryptosystems that require a strength of 80 to 256 bits are measuring their strength against an adversary brute-forcing or performing some other active discovery.
In this case, it's just the probability that two users will pick the same password and get the same salt. The attacker doesn't get to run many guesses, the database is just leaked 'as-is' and the hashes either show equality or they don't. So there is only a 1 in ~8mil chance that two in that group will show equality. Not bad for such a large population.
It doesn't then multiply up for each population. It's a sum since they are independent groups. Even then, the probability for each subsequent group will be vastly smaller as the population size decreases.
Finally, the only population at risk is users that chose such blindingly obvious passwords that they ended up in a large password population pool. These would be the same accounts that would be revealed almost immediately anyway since the obvious passwords is where any brute-forcing tool worth its salt (pun intended) would guess first.
But stuff that is universal should be a lot better. Broken Auth page is so horrendous. They mention Broken-Auth then link to a 404 Session Management page, a white-paper on Session fixation, and a paper on password recovery.
It's bad. Instead of being a wikipedia where people can look up types of vulnerabilities, OWASP should try to have more pseudo-code or real code that developers can reference. They have some of this already but they need more
^\d{5}(-\d{4})?$
^[0-9]{5}(-[0-9]{4})?$
^[0-9]{5}(?:-[0-9]{4})?$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.
If you are validating an American address, you'd want to validate using something that validates a ZIP code. If you get a Canadian address, you'd want to validate against that (which also happens to make it simple to validate against the province as well).
And yes, if you shouldn't using the term ZIP codes and postal codes interchangeably and treating them the same way in your code.
I agree in general. I think it was just a contrived example though in interest of discussing security/validation. Their example was in context of US users (and US zip-codes don't deviate from the pattern, but yes you could go one step further and reference the zip-code against the state and address using an API).
Also, specifically on regex, I'd imagine \d is being used in places where validation against unicode would be buggy (whether in form validation or elsewhere). I think Java and JavaScript default to ASCII only though.
Yes the UK has letters in postcodes.
(GIR 0AA)|((([A-Z-[QVX]][0-9][0-9]?)|(([A-Z-[QVX]][A-Z-[IJZ]][0-9][0-9]?)|(([A-Z-[QVX]][0-9][A-HJKSTUW])|([A-Z-[QVX]][A-Z-[IJZ]][0-9][ABEHMNPRVWXY])))) [0-9][A-Z-[CIKMOV]]{2})
[1] It's called 'Code Point Open' and you can 'order' it (for free) here http://www.ordnancesurvey.co.uk/business-and-government/prod...
[2] It's most of UK. It doesn't include Northern Ireland
In general, having the URL include a specific implementation quirk, such as index.php makes it more difficult to have URLs that are stable years into the future, after you may have changed technology stacks.