What passwords need is a secure password hashing method. It's a very special purpose sort of thing, different from ordinary hashing, encrypting, and key derivation. It's unfortunate that it doesn't have a proper name.
Neither "PBKDF2", B-"crypt", nor S-"crypt" are helping much with this terminology.
This is a vastly different claim than "these websites store passwords as plaintext." There are a lot of differences in assumptions and attack vectors, etc.
It usually pays for security alarms to be precise, and this site almost goes out of its way to be imprecise (and likely inaccurate). In this case, your verbiage would work great for the site in question. Why not say these are sites that don't use "secure password hashing methods" instead of making bogus unverifiable claims?
The system provides functionality for (password reset via email|sending plaintext password reminder emails|other password-based credential recovery|other delegation or retention of password-based credentials) which strongly suggests that an attacker who succeeded in (cross site scripting (XSS)|cross site request forgery (XSRF)|obtaining production server access|obtaining production database access|obtaining back-up meda|observeing network traffic|actively injecting network traffic) would then be subsequently capable of (logging into this site with a targeted user's password-based credentials|mounting on-line attacks against (a specific user's|all users') password-based credentials|mounting (dictionary|non-dictionary) off-line brute-force attacks against (a specific user's|all users') password-based credentials)|passive decryption attacks|active man-in-the-middile attacks) (with little or no work factor).
This (is|is not) recommended for (urgent) remediation. It (is likely|is not) sufficient to meet Payment Card Industry (PCI) standards or other adequate standards of care in the industry.
Check all that apply.
Also see http://cwe.mitre.org/data/definitions/719.html , for example http://capec.mitre.org/data/definitions/55.html .
I will agree with you, however, that this site is being a bit sloppy with its claims and I am going along with it because it suits my purposes (i.e., errs on the side of being conservative). But this is how security needs to work. Those claiming a system is secure should usually end up with a healthy burden of proof, whereas those claiming it's probably not should be listened to carefully.
- "I'm not storing the password in plain text, I'm hashing it after sending the email confirmation"
- "I'm not storing it in plain text, I'm encrypting it."
And of course, they would entirely miss the point that the real issue is that they are sending the password by email.
> More reading on why even _just sending the password_ via email without storing it in plain text is bad.
Which has a hyperlink to
(http://plaintextoffenders.com/post/7006690494/whats-so-wrong...)
> What's so wrong about sending a new password in plaintext? It doesn't mean that the password is saved in plaintext...
Granted, it sends a randomly generated password. And granted: it's probably meant for one-time use only (I presume). However, logging in with the new password does not automatically prompt (or even force) to change it to something of my own choosing. Result: hit 'remember password' in Chrome and forget about it. Now my active HN password is in my inbox, in plain text.
These are sites which are sending emails with passwords in the clear. They are also storing your password near the decryption key (if any), so a single security breach can compromise many passwords. That is to say: even if the rest of their infrastructure is NSA-level paranoid, whichever server(s) are sending out these password reminder emails are prime targets.
Please do not defend this behavior.
But please do not defend sloppy claims of security vulnerabilities.