Don't try to excuse bad security practice with "user experience". How good a user experience is having your passwords hacked and leaked over the internet?

There are many other better and secure ways of improving e-mail user experience. OKCupid, for example, sends out e-mails with "Login Instantly" links which contain unique keys which identify accounts. Admittedly, an e-mail eavesdropper could use one of those links to gain access to your account, but the keys can expire, can be remotely disabled, and don't contain any user data at all.

I have never heard anything about the PoF habit of sending regular e-mails containing your password, but if any service did that to me, I would immediately close my account with them and change all my passwords. I even get perturbed when companies do this as a one-off.

Security is always traded off against convenience. That's not an excuse, it's just the nature of the beast.

It's amazing how many people don't understand this. I like to tell people I can give them a 100% secure firewall. Then I tell them it's called an AirGap - do you still want it? Engineers understand that everything is a tradeoff.

Everybody knows this, it's a matter of whether it's worth it or not; where you draw the line.

POF users did indeed get the convenience of a password reminder in every email. But they also got the inconvenience of having their passwords compromised, the consequences of which could both be catastrophic and go unnoticed for a long time. In summary, not a great user experience at all; thus "user experience" is a bad excuse, especially in this particular case.

Actually not. I started using 1Password and I must say it increased both, security and convenience. No temptation to reuse the same (and simple) password, easy login ("Fill and login") and password generator with which I generated absurdly complex passwords I am using now. And I don't even have to remember them!

That would be a single point of failure for your entire online life, it would seem. I've actually got no idea how one would assess where that sat on the trade-off spectrum.

What would you consider a failure? I use 1Password + Dropbox, so in effect my passwords database is backed on three computers and iPhone. That's one additional benefit: new logins and passwords are synced.

I would consider someone else gaining access to the contents of your 1Password database a failure.

> Don't try to excuse bad security practice with "user experience"

Thank you for saying this. It's distressing how many people are rushing to his defense, by saying, basically, "well he's successful and rich, what do you know?"

I know that I'd be pretty pissed if my passwords where being stored in plain text and got leaked all over the internet - and most of the people using this non-excuse would be to.

There are plenty of ways to provide the same service of mailing out passwords that PoF has without leaving plain text passwords laying all over the place. Since the founder is supposed to be such a screaming genius when it comes to programming and running servers, I'm surprised he didn't know any of them....

To be cynical about it, you have to do a cost-benefit analysis. Is the improved user experience of being able to remind people of their passwords so much better that it brings in more revenue than what you can potentially lose from the risk of being hacked?

As I said above, this is even a false dilemma. You can have both increased security and increased usability by including one-time hashes in URLs that log users in.

Yes, that's the right way to do it, but a URL that makes the user auto-login is not the same thing as actually reminding the users of their passwords. And I bet that quite a lot of people prefer getting their password in a mail instead of a weird URL thing and being forced to enter a new password.

Remember that you and me are not the main target group of a service like this.

I'm amazed how the author of an awesome tool like hping can get this so wrong. I know you're an incredibly intelligent and capable guy, but some of the stuff you're saying here is really bad.

There's almost always a UX/Security tradeoff, but in this case the user benefit is less than the loss in security - in other words the value of the tradeoff isn't sufficient to justify the lapse in security.

Setting the cookies to expire in 2036 isn't a good idea at all. If the user has a shared PC then you've just introduced a 25 year window of opportunity for anyone with access to that system to compromise the account.

What PoF should've done is include a password reset link in the email. No need for messing around with cookies, and those that remember their password can log in just fine.

I agree with you, but this isn't a solution either. You can, quite trivially, implement sending a one-time random hash that will log the user in when he clicks it. So, you can say "you haven't been active, click here to be logged in". This is less secure than not sending the hash, but we've already established you want the user to log in from the email.

This is more secure than sending them their password and more user-friendly than having them type it in. Plus, the hashes expire after one use, so they won't be able to be reused.

Storing passwords in plaintext is an extremely bad practice.

> but in this case the user benefit is less than the loss in security

That's a highly subjective statement. Lower security makes the site more money with better user retention and it improves the user experience (as long as the site doesn't get hacked). For a bank the trade off will be different but for an online dating site I can see it makes economic sense to behave that way.

I see what you're saying but I disagree that it's subjective.

I'm saying that the benefit for the user is lower than the loss in security (to the user) with this approach.

You're saying that the benefit to the site owner is greater in this case, and I'm not sure whether it is or not (but if it's a deliberate policy I'm sure PoF would).

What is a benefit to one side is not necessarily a benefit to another.

I think that apart from our understanding of usability/security tradeoffs everyone has a different idea of what is the right ratio. I think that for some kind of applications the right ratio can be so biased to store passwords in clear texts, or alternatively to set cookies to 2036.

I mean, once all we understand that storing things in cleartext is bad, doing it is a matter of design choice. I don't recommend this techniques for most applications, but for a few it can be a possible choice.

What about not having a password at all? The user who wants to log in, request a login link to their email. And can click it within set amount of time.

Then the user only have to know the email-password. And that could be used to get a new password anyways.

Lots of sites I only visit once a year I need a new password to each time. And it would save me the trouble of making something up each time, and not remembering it anyways. And if I would try to remember it, it would likely be a password I use on another site. Which would be bad.

I think you just invented OpenID. Better, because more people have email addresses than OpenID providers, and because it piggybacks on existing infrastructure. Worse, because you don't auto-redirect past the login page.

Probably a net win.

"from the point of view of the user experience is better" Well I don't think a lot of users have a better experience now there password is exposed.

Agreed it would be nice when your old password could be recovered. But a lot of people will understand that you don't want to store there password and they will accept the fact they have to make sure they remember there password. When you know a website doesn't store your password you are likely more willing to provide a password you can remember well.

I was not referring to the user experience once the password is leaked, but if everything goes well :) But I understand your point. Part of the user experience is being comfortable with the handling of his private data.

Surely storing the passwords in plain text and making them available to users are two separate points?

If you really did want to be able to recover passwords then at least encrypt them and store the key(s) outside of the database (with options varying from "in a configuration file somewhere" through to hardware security modules at the other extreme).

[Edit: for the avoidance of doubt I think storing passwords in any recoverable form is highly dubious]

If your encryption key is stored with the databases you haven't gained much. The best thing to do is hash the passwords. It's quite common for people to say "encrypt the passwords" when they mean "hash the passwords".

You can probably do rather better than the usual approach of a general purpose hashing algorithm and a salt:

http://codahale.com/how-to-safely-store-a-password/

But then they're not recoverable, which is what the GP is talking about.

There's no benefit to recovering a current password. If you can determine that the requesting user should be able to receive the current password, you can skip that step and just ask them to set a new one.

If they are worried about user experience and that is the main reason they do not encrypt - then why not at the very least use a version of encryption that the site can decrypt? Sure, the people who grab the data can run some cryptography programs on it and eventually come up with the algorithm, but it is a hell of a lot safer than plain text.

We don't really know if they are encrypting the password while storing in the db.

> When instead the password recovery ends sending you a random password, I end doing the password recovery every time I need to enter that site.

This is what I do with 'Verified by Visa'. They make me use unintelligible passwords, so I just recover each time. It's horrible but I'm forced to.

You can store encrypted passwords without compromising user experience and usability so I am not sure what's this got to do with it?