Hacker News Reader

Agreed.

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.

PoF is to Myspace as OkCupid is to Facebook. That was always my impression.

Pedantic post: wouldn't that be PoF : OkCupid :: MySpace :Facebook?

Yes.

And nothing pedantic about it; you help him get the point of his great analogy across.

Ooh, good catch. Thanks mate.

> you may never know until something goes wrong

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.

Stealing passwords of people who log in during a limited time window is less than stealing passwords of everyone who ever registered.

That said, I agree password reuse is the underlying problem.

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.

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.

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).

> Hash based challenge-response authentication does require the server to know the plain password.

Not true. Read up on HTTP Digest authentication. It's described in RFC2617.

Oh please. That's 12 years old, it can't possible still apply.

</troll>