Why Plenty Of Fish Stores Passwords in Plain Text(grumomedia.com)
grumomedia.com
Why Plenty Of Fish Stores Passwords in Plain Text
http://grumomedia.com/why-plenty-of-fish-stores-passwords-in-plain-text/
22 comments
> 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
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.
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%)
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%)
[deleted]
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.
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?
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).
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).
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.
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.
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.
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.
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.
Or, you could do the sensible thing that other sites do - and provide them an auto-login url in the email rather than the plaintext password.
Of course, you only want to do that for medium-security stuff - if banks mailed out unrestricted auto-login URLs, sniffing unencrypted POP/IMAP traffic at a coffee shop would be rather profitable...
Two points:
1. If you're not reading mail over SSL you've got bigger problems than this; and
2. The problem is also password reuse. No one can remember a totally separate password for the 9827342 sites they've registered on. There are patterns and reuse (or a password manager, which is a little more clumsy but much safer although it then introduces other security issues). So when a password list of hacked as in this case or with Gawker, you almost certainly have compromised users' credentials on completely unrelated sites.
1. If you're not reading mail over SSL you've got bigger problems than this; and
2. The problem is also password reuse. No one can remember a totally separate password for the 9827342 sites they've registered on. There are patterns and reuse (or a password manager, which is a little more clumsy but much safer although it then introduces other security issues). So when a password list of hacked as in this case or with Gawker, you almost certainly have compromised users' credentials on completely unrelated sites.
Even if you read email over SSL, it's likely not transported that way.
Sniffing traffic on the internet backbone is orders of magnitude more difficult than sniffing traffic on an open access point. Even if you could do it, making it practical is a terrific challenge of scale.
I provide a link that will allow a password reset in mailouts.
I think that understanding of that this link is isn't as easy as recognizing a password. Everyone on the internet is used to passwords, but not to strange big links in email messages
They are more than likely to be clicking a link in the email anyway, so why not remove the barrier to entry (password). OKCupid emails have a big "call to action" button that says "Login instantly" (or something similar), you click it, you log in. Simples :)
I've seen that link and I had no idea it was an auto-login.
"We miss you. <link>Click here</link> to visit us again." - or some other sensible wording. Most pages already send you html emails, so no big change needed here.
That's silly. Email auto-logins have a time-limit (within 10-30 minutes) and a good developer would limit such email send-outs. The users would understand that email logins to the website are due to the links.
As a replacement for STORING PASSWORDS IN PLAIN-TEXT and EMAILING USERS THEIR PASSWORDS IN PLAIN-TEXT an auto-login link sent in an email without a time limit is a vast improvement.
For example, what happens if you discover you've been hacked and all of your encrypted passwords have been stolen? No big deal. What happens if you discover a hacker has stolen auto-login links for a large number of accounts? Invalidate all of the existing ones and send out new ones. Compared to the problems of getting 100% completely owned (and screwing over your customers) due to storing and sending plain-text passwords, these problems are vastly preferable.
For example, what happens if you discover you've been hacked and all of your encrypted passwords have been stolen? No big deal. What happens if you discover a hacker has stolen auto-login links for a large number of accounts? Invalidate all of the existing ones and send out new ones. Compared to the problems of getting 100% completely owned (and screwing over your customers) due to storing and sending plain-text passwords, these problems are vastly preferable.
Now you have another security hole - teaching people that it's a good idea to click links in emails, and making it orders of magnitude easier to be phished. Probably better than plaintext passwords, but still bad.
Indeed. The key thing to remember is that you don't have to be perfect to be better.
Yes, from a security standpoint it's bad practice to encourage users to click links in email, or to send one-click login links in email that don't expire in a short amount of time. However, not every website is a bank, and for the vast majority of sites protecting access to the site itself takes a backseat to securing the user's password (which more often than not tends to be shared amongst many sites).
Yes, from a security standpoint it's bad practice to encourage users to click links in email, or to send one-click login links in email that don't expire in a short amount of time. However, not every website is a bank, and for the vast majority of sites protecting access to the site itself takes a backseat to securing the user's password (which more often than not tends to be shared amongst many sites).
>For example, what happens if you discover you've been hacked and all of your encrypted passwords have been stolen? No big deal.
Encrypted passwords are just as bad, because anybody that can steal your password store can probably get at your source code, or wherever it is that you store the key.
Store hashes instead.
Encrypted passwords are just as bad, because anybody that can steal your password store can probably get at your source code, or wherever it is that you store the key.
Store hashes instead.
Do you mean the salt? Most of the time I see passwords stored it is through one-way functions, not universal keys, and in the case of a salt they would have to construct a rainbow table and even then they still wouldn't be able to get my password, its just too long. They might be able to get a string that has the same MD5 (Protip: don't use MD5s for password storage) as my password, but if its a salted password it doesn't matter anyways.
Yes, hashed with a salt, as in sha1(password+salt). Of course, then they start hunting for your code/config file/whatever, to find the salt; but it's an extra barrier.
Ah, I had a parsing error while reading your comment and I was confused. I 100% agree with you.
That's all true - but in production systems, the risk of someone getting ahold of a single password table in a database is differnet than, say, getting the source code to the production system. Just because they have one doesn't mean they have no other.
If someone can get all your production code, data, AND configuration settings, you are screwed no matter what you are doing.
If someone can get all your production code, data, AND configuration settings, you are screwed no matter what you are doing.
If you could use the unique, generated key only once, what would be the harm in not letting them time out?
I guess e-mail sniffing could be a risk... but if that's an issue then we have larger problems.
I guess e-mail sniffing could be a risk... but if that's an issue then we have larger problems.
Ideally, you want both. The link being clicked on twice is a clear red flag for a problem, but if the user requests a password and then for whatever reason doesn't click on the link that quickly, how are you otherwise going to know who's done the interception? In theory your legitimate user will be clicking on the link quite quickly (because they know when they requested it after all), so combining both increases your security.
It seems to me that there would be a benefit in checking ip addresses so that you could only click the link from the same IP that requested it. That way snoopers have even more work to do.
Not necessarily a good idea. On an average working day I'll probably use 5 different machines; I could very well trigger an action on one, go off to do something else while waiting for an email (if it wasn't instant, these things often aren't) and come back to it on a different machine altogether.
OK I'm unusual in my usage habits, but I suspect a complete IP filtering (at least without a warning about it) would cause issues.
OK I'm unusual in my usage habits, but I suspect a complete IP filtering (at least without a warning about it) would cause issues.
The seemingly apparent advantage of storing passwords in plain text is that it can be emailed to the user, as the article points out (helps with user retention). This is a bad decision and similar goals can be achieved with better means; the reason it is bad is that the password is then reversible, and hence hackable; and also the password could be sent in plain text across unencrypted protocols.
A much better way to get users back to your site who may have forgotten their password is to have links back to your site that contain special purpose unique tokens that authenticate the user into a minimal state of 'logged in' - a state that allows the user to feel logged in, eg. have visible their username, profile pic and (possibly) unread message count etc. all fields that are not overly sensitive. As soon as the user tries to make a user action such as post a message or view their own private data only then require them to enter their password.
For extra security it could also be a requirement that a cookie identifies the user's browser as being once logged in some time in the past.
This is what ebay does, and probably other sites too. You have to be very careful to make sure it's not going to comprimise any serious security, and is not suitable for all sites (eg. a bad idea for any banking site).
A much better way to get users back to your site who may have forgotten their password is to have links back to your site that contain special purpose unique tokens that authenticate the user into a minimal state of 'logged in' - a state that allows the user to feel logged in, eg. have visible their username, profile pic and (possibly) unread message count etc. all fields that are not overly sensitive. As soon as the user tries to make a user action such as post a message or view their own private data only then require them to enter their password.
For extra security it could also be a requirement that a cookie identifies the user's browser as being once logged in some time in the past.
This is what ebay does, and probably other sites too. You have to be very careful to make sure it's not going to comprimise any serious security, and is not suitable for all sites (eg. a bad idea for any banking site).
On the other hand, that would require more code, and he's made plain on many occasions that he does the absolute bare minimum of development to keep ad revenue climbing - and that he's untroubled at not bothering to fix things if it isn't actively driving off users.
Plus my gut feeling says that "here's your username and password" boosts re-logins more than a token link - there's a certain "it remembers me!" to that for non-technical users, I suspect.
Plus my gut feeling says that "here's your username and password" boosts re-logins more than a token link - there's a certain "it remembers me!" to that for non-technical users, I suspect.
Spend 5 minutes on PoF, then 5 minutes on OKC. Now tell me that PoF's user experience isn't actively repellant.
One of the strangest success stories I've ever come across, that site. Ugly design, badly thought through functionality, limited user experience and basic security mistakes too! The unhappy side of the network effect :-(
One of the strangest success stories I've ever come across, that site. Ugly design, badly thought through functionality, limited user experience and basic security mistakes too! The unhappy side of the network effect :-(
If is has your name then I think that's usually enough for the 'it remembers me' feeling.
Wouldn't be the first time ethics conflicted with making money. There's often some compromise to be made and everybody handles it differently, but that is really no excuse for storing passwords in plain text - implementing a password reset is trivial and users understand the process well.
The "You haven't been on our site for a week and we're already pretending to miss you personally" mail could even contain a password reset link.
It doesn't even need to be a reset link, it could be a link with a unique ID which logs you into the site directly.
I'd have thought that would be even more convenient than telling the user their password, as all they have to do is click a link and they're good to go.
I'd have thought that would be even more convenient than telling the user their password, as all they have to do is click a link and they're good to go.
Am I the only person that thinks that as bad as storing a plaintext password is, sending it out in an email (an unprotected communication channel) is about twice as bad of a security problem?
Not to mention the potential for creating other problems. Say you've started dating somebody that doesn't use POF or know the site does this, and they notice you're getting emails from a dating site to remind you of your password. All of a sudden you need to make them understand that you're not actively using the dating site.
They're both bad, but it's more work to intercept email. I would imagine most hackers will want to break into the core system and download a bajillion passwords all at once.
It's more work if you're targeting a single user with the intent to steal their PoF password.
But it's a lot less work if you already have access to the email account or server, or any server that the email message passes through - now you suddenly have a user's credentials, for free.
But it's a lot less work if you already have access to the email account or server, or any server that the email message passes through - now you suddenly have a user's credentials, for free.
So he made a bussiness decission: weighed the risks and went for the most profitable one.
Still, I think he's been careless. If you really want to give your users a "recover password"(especially after you have reached success), do it in a sensible way. Use hardened authentication servers behind inspection firewalls(preferably encrypted so filesystem access isn't enough!!) but don't store them in the same database as the rest of your data. Or use hashes and store the plaintext(encrypted) in another system which will do the mailing.
There are lots of options, none of them as good as slow-hashes-only solutions, but a better compromise between security and UX.
Still, I think he's been careless. If you really want to give your users a "recover password"(especially after you have reached success), do it in a sensible way. Use hardened authentication servers behind inspection firewalls(preferably encrypted so filesystem access isn't enough!!) but don't store them in the same database as the rest of your data. Or use hashes and store the plaintext(encrypted) in another system which will do the mailing.
There are lots of options, none of them as good as slow-hashes-only solutions, but a better compromise between security and UX.
I agree. Storing passwords in clear text is a security issue, but from the point of view of the user experience is better.
When the user does a few times the password recovering procedure, he'll finally memorize it. 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. And I eventually get bored enough to don't enter the site again.
Even the url in the email does not fix this issue IMHO, what the user want is typing yourcompany.com and log in, without searching for emails, at least in the long run.
Now since plaintext passwords are insecure, when it's worth using them? Only when the service is not very security sensitive, and only if you are ready as a developer to face the negative PR if something bad happens.
So: If you use plaintext passwords you should know what you are doing, and you should secure your systems very very well so that is unlikely (but not impossible...) that there will be a leak of informations in the database.
There is another usability problem related to authentication cookies expiring. Setting cookies to expire in 2036 is a good trick to avoid part of this problem. If you want to do the right thing storing hashed passwords, at least make sure that unless your data is very very security sensible, like 23andme or alike, please don't log out the user automatically.
What I like is that the authentication token in the cookie lives forever and is the same in every session opened (so you can have the same site open in office, laptop, desktop, and everything works), but once you hit "logout" in any of the sessions the auth cookie changes, and you get logged out everywhere.
When the user does a few times the password recovering procedure, he'll finally memorize it. 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. And I eventually get bored enough to don't enter the site again.
Even the url in the email does not fix this issue IMHO, what the user want is typing yourcompany.com and log in, without searching for emails, at least in the long run.
Now since plaintext passwords are insecure, when it's worth using them? Only when the service is not very security sensitive, and only if you are ready as a developer to face the negative PR if something bad happens.
So: If you use plaintext passwords you should know what you are doing, and you should secure your systems very very well so that is unlikely (but not impossible...) that there will be a leak of informations in the database.
There is another usability problem related to authentication cookies expiring. Setting cookies to expire in 2036 is a good trick to avoid part of this problem. If you want to do the right thing storing hashed passwords, at least make sure that unless your data is very very security sensible, like 23andme or alike, please don't log out the user automatically.
What I like is that the authentication token in the cookie lives forever and is the same in every session opened (so you can have the same site open in office, laptop, desktop, and everything works), but once you hit "logout" in any of the sessions the auth cookie changes, and you get logged out everywhere.
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.
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.
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....
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.
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.
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.
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.
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'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.
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.
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.
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.
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 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/
http://codahale.com/how-to-safely-store-a-password/
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.
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?
Why Plenty Of Fish Stores Passwords in Plain Text: Because they're incompetent.
That's it. You don't need to write an entire article.
That's it. You don't need to write an entire article.
It sounds like you need to read an entire article. The article argues that they're not incompetent but evil.
Essentially, plaintext allows them to email users their passwords periodically, which in turn allows them to increase user retention, security be damned.
Essentially, plaintext allows them to email users their passwords periodically, which in turn allows them to increase user retention, security be damned.
I read the article. It's nothing but speculation and I don't buy it.
Emailing them their password gives higher retention than being sent to right location when you click on a link that automatically logs you in? Yeah, right.
Maybe that's how Markus justifies it to himself too but it doesn't make my original statement any less true.
Emailing them their password gives higher retention than being sent to right location when you click on a link that automatically logs you in? Yeah, right.
Maybe that's how Markus justifies it to himself too but it doesn't make my original statement any less true.
There are a lot of sites guilty of this, even those that should know better. In 2009, I lost my username to the Microsoft TechEd Africa site. So I phoned Microsoft South Africa's number for the event, and I was shocked when the chap at the other end read my password back to me!
It was a strong password that I used on a few other low-importance sites, but I immediately changed it on all of them.
It was a strong password that I used on a few other low-importance sites, but I immediately changed it on all of them.
"Every so often, POF sends you an email with your password so you don't forget it."
I threw up i my mouth a little when i read that. Stupid crap like that is what made me switch to 1password, so if some random guy in a coffeeshop looking over my shoulder does see a plaintext password, it will be too difficult to remember, and will only open up one website.
Hello, haven't they ever heard of auth tokens?
I threw up i my mouth a little when i read that. Stupid crap like that is what made me switch to 1password, so if some random guy in a coffeeshop looking over my shoulder does see a plaintext password, it will be too difficult to remember, and will only open up one website.
Hello, haven't they ever heard of auth tokens?
I've never heard of Plenty of Fish, so I don't know what they do or what kind of user data they store. But I'll take a contrary point of view and say that for some services, light security is good enough.
Mailman, the mailing list management software that's widely used, emails you a password reminder once a month. They warn you when you sign up that your password is not really providing "real" security and not to use a valuable one.
This is the strategy he was employing... sending users a reminder of their password and keeping them engaged in the site.
Now, I do think they should tell people, when they are signing up, that they will get reminder emails of their password and not to use e.g. their online banking password here. If I know this going in, and depending on the nature of the site and what personal data they have, I might be OK with this.
Mailman, the mailing list management software that's widely used, emails you a password reminder once a month. They warn you when you sign up that your password is not really providing "real" security and not to use a valuable one.
This is the strategy he was employing... sending users a reminder of their password and keeping them engaged in the site.
Now, I do think they should tell people, when they are signing up, that they will get reminder emails of their password and not to use e.g. their online banking password here. If I know this going in, and depending on the nature of the site and what personal data they have, I might be OK with this.
It's interesting how much discussion there is here on ynews about the "Right" way to handle paswords... if it's so simple, why can nobody really agree?
A few things to consider.
1) storing plaintext passwords is a bad practice. It's fundamentally a bad practice because if someone gets ahold of a database table containing your names and passwords, you immediately have to change them all. You're broken, wide open. 2) storing passwords encryption, where the necessary apps have the keys, but the DB itself only has encrypted data. now if someone steals your DB, your passwords are relatively safe, unless someone ALSO managed to break into the right production app server and extract the key. This is acceptable for storing credit card numbers for PCI compliance... should be good enough for your website. If the DB is breached, you are still going to through a password changing exercise, but you have time to do it without going into panic mode.
3) Hashed passwords + salt. It's worked well in unix for years. It's fine for web apps where you don't want to be able to recover a password, only reset it. Note the salt is really important here... it lives in your app, not in your DB. The idea is that if someone gets ahold of your DB, again, they can't just brute-force what they see because they don't know how you've salted it. You've made it much harder.
A few things to consider.
1) storing plaintext passwords is a bad practice. It's fundamentally a bad practice because if someone gets ahold of a database table containing your names and passwords, you immediately have to change them all. You're broken, wide open. 2) storing passwords encryption, where the necessary apps have the keys, but the DB itself only has encrypted data. now if someone steals your DB, your passwords are relatively safe, unless someone ALSO managed to break into the right production app server and extract the key. This is acceptable for storing credit card numbers for PCI compliance... should be good enough for your website. If the DB is breached, you are still going to through a password changing exercise, but you have time to do it without going into panic mode.
3) Hashed passwords + salt. It's worked well in unix for years. It's fine for web apps where you don't want to be able to recover a password, only reset it. Note the salt is really important here... it lives in your app, not in your DB. The idea is that if someone gets ahold of your DB, again, they can't just brute-force what they see because they don't know how you've salted it. You've made it much harder.
I don't mind some websites storing passwords in plaintext for convenience reasons. But if you are storing them like that than at least warn the user at registration time so that they know this is not going to be as big a secret as they hoped.
I don't mix my banking password with my forum passwords, but I'm running out of easily rememberable, for me, passwords that don't require me to use a password manager instead of mnemonics.
In other words, fuck this shit man!
I don't mix my banking password with my forum passwords, but I'm running out of easily rememberable, for me, passwords that don't require me to use a password manager instead of mnemonics.
In other words, fuck this shit man!
At least Half Encode password, as a reminder. 50% plain text, 50% hashed out.
Or a temporary login token url.
Never send users plain text passwords in email.
Never send users plain text passwords in email.
On the other hand, when I tried Plenty of Fish, the fact that they sent me my password in plain text completely turned me off the service.
Chances are you're not the target audience.
Not true I bet there are plenty of hackers that are single and looking for love! I go on there even though I don't like the website and its functionality once a week just to see who's around.
> Nope, Markus is no fool so if he stores passwords in plain text is for a reason, and a good one indeed.
There is no such thing as a good reason to store passwords in plain text, just as there's no good reason to email it to a user once a week.
I touched on this last night in my talk at the London HN Meetup, PoF are very clearly 'doing it wrong'.
There is no such thing as a good reason to store passwords in plain text, just as there's no good reason to email it to a user once a week.
I touched on this last night in my talk at the London HN Meetup, PoF are very clearly 'doing it wrong'.
There's only one excuse for storing passwords in plaintext - to perform challenge-response auth, so passwords can't be sniffed. A tradeoff between line and database security. Of course, this is only applicable in cases when two special conditions are met:
a) The line is considered not secure enough. YMMV here.
b) There's no possibility to use some kind of more secure method (for example, deploy a PKI, ZKPP or PAKE). Like when you're ISP offering PPPoE access (lots of SOHO routers just don't know about EAP at all).
So this is definitely not about web sites (as they could - and really should - use HTTPS).
a) The line is considered not secure enough. YMMV here.
b) There's no possibility to use some kind of more secure method (for example, deploy a PKI, ZKPP or PAKE). Like when you're ISP offering PPPoE access (lots of SOHO routers just don't know about EAP at all).
So this is definitely not about web sites (as they could - and really should - use HTTPS).
What's wrong with storing passwords encrypted with a key you know but don't store the key on the server?
Yes, the attacker could read the key out of the running server, but that requires way more sophistication than just dumping a database. You could still send plain text password to people, if that's how you roll (I don't!) and the implementation is rather straightforward.
Yes, the attacker could read the key out of the running server, but that requires way more sophistication than just dumping a database. You could still send plain text password to people, if that's how you roll (I don't!) and the implementation is rather straightforward.
Sending clear text passwords in email might itself be in an issue. However, if all he wanted was to regularly send clear text passwords in email to the users, he still could have encrypted the passwords before saving it in the database. And when sending password to user, decrypt it while taking out of db and send it.
> ... what is most likely, that a guy that has build the largest free dating site the world is a moron? or that his ambition overrules any concern for his user's privacy?
I don't beleive these are mutually exclusive choices. One who is ambitious at the expense of his users' privacy is indeed a moron.
I don't beleive these are mutually exclusive choices. One who is ambitious at the expense of his users' privacy is indeed a moron.
[deleted]
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.