My opinion? PoF stores password in plain text because it is an unprofessional outfit with no care for the security of its users or their data.
There is no valid reason for storing plain text passwords. Every time someone says "but we want it because we need to X" there is a better way to achieve X (or Y, where Y has the same effect as X in the end) that does not require plain text password storage (but may require a little extra coding+testing).
If anyone who says that the "but may require a little extra coding+testing" constitutes a valid reason, then they should not be trusted with any of your data. It is like leaving the office door unlocked because you couldn't be bothered to fish your keys out of your pocket and find the right key. It is an excuse (a pathetic excuse) for plain text passwords, but it is not a valid/good/acceptable reason.
Of course there are probably a great many sites that are unprofessionally constructed (in the auth credentials storage area at least) and you may never know until something goes wrong, so for safety you should not use the same password for multiple sites (keepass and similar utilities make keeping track of multiple password easy enough) then at least if one site is hacked the perp only gets access to that one site as you rather than potentially many sites.
How does OkCupid achieve the same thing? They use unique tokens in the URL's of their mails, so you are instantly logged in if you visit OkCupid through any URL in their mail. It's safer, and even easier than how PoF does it, because you can just click the link instead of having to copy/paste your password into the login form.
I think it's been shown that PoF is unprofessional enough times already to discredit this whole article. Judging the evidence, Occam's razor tells me Markus is an amateur who was in the right place at the right time with a poor product, and unlike Craigslist or other projects that started out this way, he hasn't improved it at all, and is riding the wave of success from his initial userbase.
There are some warning signs that clue you in. Any of the following are good indicators that passwords are not being stored properly:
- Passwords emailed in plaintext on registration (minor flag - may be stored properly, but not good practice)
- Passwords emailed in plaintext at any other time (definitely stored incorrectly)
- Maximum length
- Not allowed special characters
- Including a " or ' in your password causes an error
I don't know - maximum length/special characters in passwords I find are enforced pretty much everywhere.
I used to keep my KeePass rule pretty liberal. Any 30-character length string would get generated. More than a few times I've had to either decrease the length or remove characters. I had to drop the length and keep it alphanumeric just to avoid the hassle. Plus, typing weird characters on a mobile device gets old fast (thankfully, KeePass exists on Droid, but boostrapping dropbox + KeePass is still annoying).
What's even worse is when password registration silently drops data. You'll register with one password, and attempting to log back in fails because the page that stored the password and the page that you log in on are using two (probably subtly) different decoding methods.
My LastPass is set to 20 characters, alphanumeric + specials. I don't have to bump it down that often, but the majority of sites I register on are quite geeky. It's generally less geeky places such as shops, government services, online banking that don't accept my passwords (yes - exactly the places where I WANT a strong password). Maybe I've run into issues less than you because mine is only 20 characters not 30.
Here's some raw numbers:
Passwords: 336
Average password strength: 97.5 %
Average password length: 17.9 characters
Number of weak passwords: 3
(For reference, a 20 character password with specials is 100%, with just letters and numbers it comes in at 98%)
The real problem -- and the reason for most of the outrage -- is password reuse. Can we all agree yet that password reuse is the actual problem, and not the storing of passwords?
We should reframe the discussion around that, because it is the real issue.
But let's pretend that PoF stores a 128-iteration blowfish ciphered password for every user. The site is compromised, as it was, and the attacker now has the run of the place. They inject their capture into the login process and now they siphon off every plaintext password.
On the scale of things, whether the password is stored hashed or not is very, very low. It masks the real problem.
Passwords are the problem. They're invariably hard to remember or easy to guess. Or to abstract it out, you're always choosing between resistance to getting lost and resistance to attack.
Such an exploit could be in place on countless sites you visit daily, with no one the wiser. Further, aside from technical competence, why does anyone trust PoF? Why do they trust any site to not only technically handle their password correctly, but to not subvert it for their own purposes?
I see that my post above got moderated down. People want to lazily, and sloppily, reuse passwords everywhere. It's ignorant. The world would be better if we got rid of this ruse that sites hashing passwords themselves offers any reasonable protection. It leaves the barn door open.
The only scenario I can imagine where storing passwords in plain text is acceptable is when you are going for a CRAM-MD5 sort of authentication where the actual password will never go across the wire and even then it is a hell of a trade off and there are alternatives.
I'd forgotten that one. Hash based challenge-response authentication does require the server to know the plain password.
This sort of authentication is useful when you don't trust your transport mechanism (i.e. logging in over HTTP) but do trust the server's security. There are other ways to achieve this though. You could use DH or a similar key exchange method to decide a secret key (DH can do this without letting eavesdroppers know the key) to encode the password with for transport. You are then avoiding both plain transport and plain storage, where hashed storage on its own requires plain transport (unless the transport mechanism is separately encrypted, by SSL/TLS in the case of HTTPS) and hashed challenge/response requires plain storage.
Securing the transport (by using HTTPS with a signed-by-a-generally-trusted0body certificate, rather than HTTP or HTTPS with a self-signed cert) is the better option for a web based application though.
Of course, a site like PoF is not going to use any of the above. As has been identified (and, assuming statements in other comments here are true, admitted) convenience and laziness on the part of the programmer are far more important to them than DoingThingsRight(tm).
There is no valid reason for storing plain text passwords. Every time someone says "but we want it because we need to X" there is a better way to achieve X (or Y, where Y has the same effect as X in the end) that does not require plain text password storage (but may require a little extra coding+testing).
If anyone who says that the "but may require a little extra coding+testing" constitutes a valid reason, then they should not be trusted with any of your data. It is like leaving the office door unlocked because you couldn't be bothered to fish your keys out of your pocket and find the right key. It is an excuse (a pathetic excuse) for plain text passwords, but it is not a valid/good/acceptable reason.
Of course there are probably a great many sites that are unprofessionally constructed (in the auth credentials storage area at least) and you may never know until something goes wrong, so for safety you should not use the same password for multiple sites (keepass and similar utilities make keeping track of multiple password easy enough) then at least if one site is hacked the perp only gets access to that one site as you rather than potentially many sites.