
Why Plenty Of Fish Stores Passwords in Plain Text - grumo
http://grumomedia.com/why-plenty-of-fish-stores-passwords-in-plain-text/
======
dspillett
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.

~~~
ZoFreX
> 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

~~~
Splines
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.

~~~
ZoFreX
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%)

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

~~~
va1en0k
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

~~~
Joakal
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.

~~~
InclinedPlane
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.

~~~
anthonyb
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.

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

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

~~~
mst
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.

~~~
eftpotrm
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 :-(

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

~~~
limmeau
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.

~~~
rlivsey
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.

------
brown9-2
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?

~~~
anthonyb
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.

~~~
brown9-2
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.

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

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

~~~
Herald_MJ
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.

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

~~~
gaius
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.

~~~
tjogin
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.

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

~~~
lukeschlather
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.

~~~
smokinn
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.

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

------
thinkbohemian
"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?

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

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

------
yardie
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!

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

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

~~~
jarek
Chances are you're not the target audience.

~~~
TheBranca18
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.

------
iuguy
> 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'.

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

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

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

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

