
OWASP Cheat Sheet Series - aburan28
https://www.owasp.org/index.php/Cheat_Sheets
======
ctz
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.

~~~
hueving
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.

~~~
ctz
Let's consider Adobe, since we have actual data. Of 130,324,429 users, we know
1,911,938 chose the password '123456'. Consider just that population of users.

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!

~~~
hueving
> is about 2^-23. That's not good -- usually cryptosystems are designed to
> have a probability of failure between 2^-80 and 2^-256.

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.

------
logn
On their Input Validation cheat sheet
([https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet](https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet))
they recommend this as an example zip-code validation:

    
    
      ^\d{5}(-\d{4})?$
    

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:

    
    
        ^[0-9]{5}(?:-[0-9]{4})?$

~~~
mweibel
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.

~~~
jasonlotito
ZIP codes are an American thing. ZIP codes are a specific system of postal
codes. If you are talking about ZIP codes, it's American.

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.

~~~
mweibel
Interesting. I'm swiss and usually our postal codes are translated to zip
code. Would postal code be the generic translation then?

------
davedx
[https://www.owasp.org/index.php/Web_Service_Security_Cheat_S...](https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet)
\- ugh, "containers", SOAP and XML. Was hoping for something more general.

------
wglb
One of the better examples of an OWASP cheat sheet is Rsnake's XSS:
[https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...](https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

------
tharri
Does the fact that this site has "index.php" in all its URLs bother anyone
else?

~~~
ADFASFGADA
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.

~~~
e1ven
I tend to be rather language agnostic, but URLs should generally be a
descriptor of the content, and leak as few technological details as possible.

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.

------
Fasebook
or "How to make sure only the NSA can circumvent your security"

