Adding Server-Side Plaintext Credentials Storage Classification about vulnerability-rating-taxonomy HOT 7 CLOSED

I am in favor of option 2 unless a good case can be made against it.

from vulnerability-rating-taxonomy.

+1 for option 2

from vulnerability-rating-taxonomy.

+1 for option 2 as well

from vulnerability-rating-taxonomy.

agree for the option 2

from vulnerability-rating-taxonomy.

I'm not sure I agree with either option. "Defeatable Cryptography" is a bit generic, but more importantly, there is very little difference between passwords stored as plaintext and, for example, passwords stored as unsalted MD5 hashes - a database using the latter can usually be cracked up to 90% in a very short amount of time, and up to 99%+ with some effort and more time. Another example would be passwords stored encrypted (rather than hashed), in which case if, the attacker can also recover the encryption key, the whole database can be instantly "cracked".
To sum it up, I'm not convinced it is the right thing to differentiate between plaintext / non-plaintext, and think a different metric should be used.

from vulnerability-rating-taxonomy.

Thanks for chipping in @truemongo. We're definitely on the same page, but at the same time we are facing a problem of maintaining a concise and effective crowdsourced vulnerability taxonomy. Plaintext password storage entry leaves no room for misinterpretation, but there's no straightforward way to classify other weak password storage implementations, hence the proposal of having a catch all P5 entry (option 2), that can be upgraded on a case by case basis or simply not having it at all (option 1).
Other than no salt or exposed encryption key, it is difficult to draw a line between weak and good enough password storage cryptography. To name a few: exposed salt, weak salt, fake encryption, weak hashing/encryption algorithm, or even lack of PBDKF etc. It doesn't seem to be practical (or foolproof) to address all of possible variants and so far the two options mentioned above are the only reasonable ones. We would love to hear if you have any suggestions though.

from vulnerability-rating-taxonomy.

After consulting with the team we have decided to add just one entry:
Insecure Data Storage->Server-Side Credentials Storage->Plaintext (P4)

This solution while not disincentivizing submissions of potentially valid weak cryptographic implementations will also leave the doors open for any future variants.

from vulnerability-rating-taxonomy.