

Plain Text Offenders - Did you just email me back my own password?  - omervk
http://plaintextoffenders.com/
"We’re tired of websites abusing our trust and storing our passwords in plain text, exposing us to danger. Here we put these websites to shame."
======
linker3000
Nothing new there! When we setup a new in-house account, we either telephone
the user or go to see them with their password. If it's a senior Manager with
a corporate phone they get their password texted to them - Ok, not ultimately
as secure as possible but a darn sight more secure than a plaintext email.

In my previous job I was asked to FTP our full client list (with financial
information) to a third party acting on behalf of the company that had just
acquired us. The IT Director of our new owners kicked up a hell of a stink and
accused me of being 'unhelpful' because I insisted on the third party signing
an NDA and installing AxCrypt so that I could encrypt the data for
transmission. In the end I just said that if they insisted I send everying
without encryption, I wanted it in writing with a disclaimer that I was acting
on their instructions and they would assume responsibility for any possible
liabilities arising with respect to UK Data Protection Laws.

By the time the IT Director had deliberated the point, the third party (who
fully appreciated my position) had sent me a stock NDA, installed AXCrypt and
we'd completed the transfer.

~~~
va_coder
You say you telephone the users.

What if they are traveling? How do you verify the other person on the phone is
who they say they are?

~~~
JonnieCache
_> How do you verify the other person on the phone is who they say they are?_

This came up in another thread some time ago, and it was suggested that one
very simple way to do this is to have the person call you back.

Ultimately though there is no real solution to this problem except meeting the
person face to face.

~~~
linker3000
That pretty much covers it. We telephone them in house on their extension
number and there's only 60-ish employees so we know their voices. Externally
they have to call back.

------
estel
The worst offender I can recall was Wordpress.com. Not only do they email you
your password back, but show it to both you and whoever might be sitting
within a few metres in LARGE LETTERS in the webpage immediately after
activating your account.

After I emailed to complain about this, they said:

"Security and usability is often a trade-off. We make two main ones:

* When you register at WordPress.com, we show you your password and email it to you. * When you log in we tell you whether the username or password was incorrect.

The accessibility and increased convenience for users in both cases has been
deemed to be worth it."

Edit: I just checked, and it seems that they've changed this element of their
policy. The situation above was March 2009.

~~~
Kudos
At least it's some consolation that they don't store the password in plain
text, unlike plentyoffish.com. Do they also email you your new password if you
change it?

~~~
JonnieCache
A secure website should be mathematically incapable of ever displaying your
plaintext password in any form whatsoever, at any time, even during the
registration process.

~~~
archivator
How so? You can easily send out an email with the plaintext password, hash it
and store it securely from then on..

~~~
colinhowe
What if you log all sent e-mails?

~~~
alinajaf
Then you have a great big log full of passwords, pretty much negating any
security benefit of hashing them in the first place.

------
aslakhellesoy
<http://passwordfail.com/> lets people register the offenders. If you have the
passwordfail chrome extension installed, you will get a warning whenever you
visit an offender. Highly recommended.

------
pbhjpbhj
Mailman ...

My LUG uses it and mails me my password in plaintext every month; IIRC it
is|was the default setting ... /me-rolls-eyes

~~~
ig1
To be fair the Mailman registration page explicitly tells you not to use a
secure password as it'll be mailed back to you in plain text.

~~~
sigzero
And to be fair, you can't really do anything with that password except change
your subscription status. That said, version 3 is in the works and I read that
"feature" is going away.

~~~
pbhjpbhj
I don't know, do the admins not get sent the email too as they are subscribed?
It's a loooong time since I used mailman.

------
compay
Codeweavers, the creators of Crossover for Linux and OS X, do this. I emailed
them about it around a year ago and they never bothered to reply back, even
though I've bought several licenses from them over the years.

<https://www.codeweavers.com/login/>

------
gabbo
By far the worst example I can think of here is Yodlee, the bank aggregator.

Their product, Moneycenter, has this convenient "feature" which lets you
display your bank password in plaintext! It's unthinkable that _someone you
trust with your bank credentials_ would let their website be a two-way street
for plaintext bank passwords.

Things like this remove any confidence I may have had in their product. The
fact that a feature like this exists at all is strong evidence that they're
neither thinking in a security mindset nor paranoid on behalf of their users.
If someone proposed this "feature" where I work they would be laughed out of
the room.

If that wasn't bad enough their support folks politely ignored me when I
raised the issue and pleaded with them to turn it off. They either don't get
it, don't care, or don't know how to escalate issues to people who do:

    
    
      Please be assured that Yodlee considers account/data
      security as highly critical and hence will not be revealed
      to any other source. 
    
      We suggest you not to reveal your account login credentials
      i.e answers to security questions & password, to anybody.
      This will ensure your account will not be compromised. 
    
      Thank you for your feedback on the product. We appreciate it. 
    
      We are marking this Service Request as Resolved. Please let us
      know if you have any questions in this regard.

~~~
ars
How are they supposed to log in your sub-accounts without the password? They
have no choice except to store the plain text password.

And they don't just show you the password - they make you enter your login
password first.

What exactly do you want them to do? You aren't thinking this issue through.
Do you just want them to hide the password from _you_? What would be the
point? They still have it.

They also have a one-click login to your subaccounts, so even if they don't
show you your own password it wouldn't be enough. I suppose you want this
feature disabled too?

The point of not storing plain text password is not to avoid displaying them,
it's to make sure no one else can steal them.

But yodlee has no choice, they must store it plain text. And once they do,
displaying it - only upon your explicit request (so it's not accidentally
displayed), and after you enter your password, seems reasonable to me.

~~~
gabbo
I'm sorry but you're really not (a) paranoid enough and (b) thinking
defensively (c) accepting the reality that users will make poor security
decisions (d) recognizing that a service should do everything in their power
to mitigate threats to their customers. Yodlee does a good job in many areas
(security questions, special phrases and images, secondary password prompt for
"riskier" operations) but still falls short here.

I realize that my credentials need to be efficiently convertible to plaintext
at runtime within their service. They still shouldn't be stored in plaintext
(it shouldn't be easy for engineering and operations staff to see my bank
password by just looking at a database dump) though. In any case, I took the
leap of faith that I trust Yodlee to keep my bank credentials secret when I
signed up for their service in the first place. This is not what I was talking
about.

I realize they force you to enter your password first. This is good but
doesn't mitigate the threat I had in mind in the first place. It's Yodlee's
responsibility to minimize the risk their service poses to their customers.
Unless they can be 100% sure that the person signing in with my Yodlee
credentials actually _is_ me they need to consider the implications if it's
not. Off the top of my head here are two obvious situations where Yodlee's
"display plaintext password" feature puts users at higher risk:

1\. User accesses Yodlee from a computer (maybe theirs, maybe their friend's,
maybe a public terminal) which has a keylogger installed on it.

2\. User is not security-conscious and doesn't realize the implications of
this feature. Thinking Yodlee is read-only (like most other competing
services) they use a weaker password than they should or even use the same
password for Yodlee as on other sites. They shouldn't but it's a fact of life
that they do.

In both cases the attacker can get the user's Yodlee password and then all of
their bank passwords. They steal all of the user's money. Banks are generally
willing to play ball and cover users for their losses if their account _at
that bank_ is hacked. Will they step up in the same way if they're hacked via
Yodlee? I'm inclined to believe the answer is no. I don't even know if the
bank should be expected to.

When choosing whether or not to build a feature, you need to consider whether
its benefits outweigh its risks.

Trusting Yodlee with my bank credentials to aggregate financial data is a risk
but doing so is the entire basis for their service and provides me with a huge
amount of value. It enables scenarios which are otherwise completely
impossible.

This "show plaintext password" feature is a small convenience which doesn't
enable any new scenarios and has some pretty significant risks.

EDIT: I'm aware of the auto-login feature but didn't bring it up because it's
almost the same as displaying plaintext passwords. Practically speaking it's a
tiny bit less bad because an attacker can't directly view the password and use
it on other services (assuming again that users make poor decisions and use
the same password everywhere). Either way I think both should be gone.

~~~
ars
> They still shouldn't be stored in plaintext

So how are they supposed to get your data from your bank if they can't login
to it?

> User accesses Yodlee from a computer (maybe theirs, maybe their friend's,
> maybe a public terminal) which has a keylogger installed on it.

Just change "Yodlee" to "your bank" and the same exact problems happen. There
is nothing special about Yodlee here.

> User is not security-conscious ..... they use a weaker password than they
> should [on Yodlee]

And when Yodlee asks them for their bank's password they don't realize what's
going on?

I personally _like_ that Yodlee is explicit in saying to you "We have your
bank password, be careful with your login". As opposed to making it seem like
they have some backdoor, or authentication token to your bank, which they
don't.

It's exactly the opposite of what you think - by letting you know they have
the password you will be more security conscious with them. If that feature
did not exist you might think that they were a "read only view".

> .... auto-login feature .... Practically speaking it's a tiny bit less bad
> because an attacker can't directly view the password and use it on other
> services

Do you think it works by magic? How do you think it logs you in to the other
site? It uses your password! It makes an auto submitting form that has your
password in it, in plain text, right there in the javascript!

~~~
gabbo
> So how are they supposed to get your data from your bank if they can't login
> to it?

Like I said, there's no requirement for credentials to be STORED in plaintext.
They just need to be readily convertible to plaintext when they pull your
data. I'm thinking about a system where credentials are encrypted and access
to the keys are locked down (either via software or hardware) so that
engineers and operations don't have unimpeded access.

> Just change "Yodlee" to "your bank" and the same exact problems happen.
> There is nothing special about Yodlee here.

Two things:

1a. Like I already said, many banks protect their users from losses incurred
if someone gets hacked while using the bank's online portal. They'll bail me
out if someone gets access to my account and takes all my money. Will they
bail me out if Yodlee is used as an attack vector? That would be nice but I'm
not convinced that banks/brokerages/etc. will step up and help me out in that
situation. Ideologically I don't even know if banks should be _expected_ to.

1b. Will _Yodlee_ bail me out if an attacker uses them to steal all my money?
Nothing on their website indicates that they will. Even if they did,
implementing these risky features just adds more risk and uncertainty to their
business for a feature which isn't ultimately that worthwhile.

2\. Yodlee is special because they're an aggregator. That makes them a
significantly more valuable target than one bank alone. I have various
accounts at various places, if someone got access to one of them at least the
damage is contained. With Yodlee they get everything at once.

> And when Yodlee asks them for their bank's password they don't realize
> what's going on?

You'd hope so but can't assume, you're not just selling to technical and
security-conscious users. Most of Moneycenter is looks like it's dedicated to
read operations. There are just a few innocuous-looking links in the account
management section which opens up this whole can of worms. I came to Yodlee
from Mint, who doesn't expose _anything_ in their UI which would allow writes.
That was my expectation because write access via this kind of service is
unthinkable to me. After I explored a bit and realized this I removed all my
accounts.

> It's exactly the opposite of what you think - by letting you know they have
> the password you will be more security conscious with them. If that feature
> did not exist you might think that they were a "read only view".

I get where you're coming from but I think this is a stretch. If they're
really trying to be upfront with their users about what can and can't be done
they would be more explicit than two links for "auto-login" and "show my
password".

Maybe the disconnect is that I want a read-only financial aggregator (i.e.
Mint) whereas Yodlee tries to do more... but from my brief experience with
Yodlee I didn't really even see many things that directly did writes. Most of
the value I saw was in the reading/reporting.

> Do you think it works by magic? How do you think it logs you in to the other
> site? It uses your password! It makes an auto submitting form that has your
> password in it, in plain text, right there in the javascript!

Sorry, I wasn't really clear in my haste to edit the last reply. I know auto-
login is only trivially and superficially different from showing a plaintext
password. That's why I didn't even mention it at first.

EDIT: Actually I think the current implementation of auto-login may be worse
than showing the password in cleartext. IIRC the user doesn't have to provide
Yodlee credentials a second time like they do to view their bank password.

------
nyellin
There are some cases when storing plaintext passwords is justified, despite
all of the risks. There are cases where you can't - or shouldn't - hash
passwords.

For Freeversation, we store plaintext passwords for two reasons:

1\. Our passwords are _group_ passwords, which (hopefully) aren't re-used
anywhere else. If someone hacks our server, the conversations stored on it are
incredibly more valuable than the passwords themselves, which aren't
associated with a specific email address or account. Our approach to security
is that unauthorized access to our server is checkmate. That _is_ the worst
case scenario, not stolen passwords.

2\. When you create a new conversation, you can invite new users to the
discussion. Those users didn't sign up for Freeversation - and in all
likelihood never heard of Freeversation before - but they're expected to
remember a password that someone _else_ chose. We help them remember that
password by including it in every notification email we send. (E.g. emails
inviting them to the conversation, emails notifying them of new comments,
etc.) We wouldn't be able to do that if we hashed passwords.

In our case, the alternative to plaintext passwords is actually getting rid of
passwords altogether and replacing them with secret URLs. We chose plaintext
passwords because they provide psychological reassurance that conversations on
Freeversation are invite-only, and not public. The irony is that secret URLs
are actually _more_ secure than the passwords that most of our users choose.
In the future, we may use a combination of the two, so that users both feel
protected and are protected in the best way possible.

~~~
kunley
The catch is in the word _hopefully_.

Wishful thinking is not a successful way of doing things in engineering.

~~~
nyellin
If someone creates and conversation and re-uses a password, that password is
emailed to everyone they invited. There is no way to avoid that and still use
a _group_ password.

Edit: Furthermore, the password is not associated with a specific email
address or user name. Even if someone has access to a conversation's password,
they don't know who the password belongs to.

~~~
bmelton
I don't know your use cases, so pardon me if this is naive, but couldn't you
create a token that is unique for each user, and is consumed after use?

~~~
nyellin
I'm not sure what you have in mind.

Our use case is explained on freeversation.com/about. Let me know if you have
any questions.

~~~
bmelton
Okay, having read that, I agree -- you absolutely don't have to worry about
password theft. At least, not after the fact of a conversation having already
happened.

However, what I was suggesting, is that instead of using a group password:

\- create a random password for each user that is invited \- as part of the
'login' process (or room join process, depending on how your code is
structured), check to make sure that token exists in the database \- as soon
as somebody uses that random password, delete it (or mark it inactive)

This means that for each token, there can be exactly one login. That login
should belong to who you sent the email to, and nobody else. It's just as
anonymous as your method, and slightly (wee bit) more secure.

This also solves the problem of people sending the password to their friends,
though obviously cannot plug the analog hole of allowing their friends to look
at their screen.

------
colinhowe
I've been wanting to make this for ages. Very pleased to see it made!

Would be awesome to have a notable offenders section. A chrome plugin that
hooks into this would also be cool: "This site has rubbish password security.
Don't use your usual passwords"

~~~
hmemcpy
It's already planned :) Stay tuned!

~~~
blauwbilgorgel
Better add rel="nofollow" too. Or do you want to vouch for all these pages? If
your PR rises, expect people to create plain-text systems just to get a
dofollow link.

Also, do you check each and every service you put up? Or do you trust the
random internet visitor to always do the right thing? Are you ready for and ok
with any collateral damage?

------
jeza
Seems that in many cases you get a choice between security over the wire or
security in storage, but not both. By this I mean if you use a challenge
response authentication algorithm then you often don't have any choice but to
store the password in cleartext. Then authentication can be done even over an
unencrypted channel without revealing the password.

The compromise seems to be to store the password with a oneway hash then use
an encrypted channel such as TLS to send the full password for each
authentication. There is still the possibility of intercepting the password at
the end of this encrypted channel before the password is compared to the
stored hash.

So both models have weaknesses, it just means you have to focus your security
efforts into a different area. For the first, it might be somewhere deep in
the backend, for the second you'd be paying attention to the front end where
you accept the TLS (e.g. https) connection.

This has certainly been the case with for example PPP where you had a choice
between PAP (secure storage, but sent in plain text) or CHAP (insecure storage
but not sent over the wire in full). Jabber/XMPP servers also traditionally
store in plain text but passwords aren't sent for each login. Though it seems
that HTTP Digest auth does allow storage of passwords in a hash without
transmitting the full password.

Then even with challenge response algorithms if someone is able to monitor a
number of authentications then they may be able to gather enough information
to pose as that user without actually knowing the password.

~~~
temptemptemp13
If I understood you correctly - there doesn't need to be a tradeoff between
wire and storage security.

You could use a oneway hash at the client side as well.

If you don't want to divulge what's the hash in your database, you can add
another oneway hash for whatever reaches the server.

The challenge-response can also be based on hashes.

------
tnorthcutt
I tried to submit a screenshot, but got the error message _Sorry, your page
had expired. Please try again._ on the submission screen. Either they're
having trouble (and displaying an unhelpful error message), or they have an
awfully short page expiration time - from page load to the time I hit submit
was under 30 seconds.

~~~
omervk
This is a tumblr issue. I think it has something to do with Chrome. Did you
use that?

~~~
tnorthcutt
Yes.

------
enewcomer
Here's my experience trying to bring this to one of the offenders' attention.
He actually attempted to justify it.

[http://eric.newcomer.org/jamplay-defends-storing-
passwords-i...](http://eric.newcomer.org/jamplay-defends-storing-passwords-in-
plain-te)

------
jcsalterego
Rackspace does this with their Cloud Servers :'(

~~~
asharp
Surely your joking, Mr. Alterego?

~~~
emp_
Well, they do sent root passwords over email.

~~~
goosemo
if it was the welcome message, that's not a problem. It's up to you to change
it. If they're emailing you your password to root after you've changed it, you
might have an issue.

~~~
MartinCron
Exactly, I'm using SoftLayer cloud servers and they do the same thing...
displaying a cleartext version of the initial root password for the machine. I
don't see a way around it. I do have to _get_ that information somehow.

~~~
JonnieCache
EC2 servers dont have any passwords at all by default. Not blank ones, but
there are actually none set at all. They come primed with a keypair which you
get when you create your account.

Considering we live in space year 3000 now, its a wonder that we still have
passwords at all. Why can't we have 2 factor keypair authentication for
_everything?_ OpenID is thinking too small.

------
acidblue
I forgot the password to my credit union account. I clicked on the 'get
password' link and they e-mailed my original password back to me, in plain
text. Lame! I still need to move my funds though, doh!

------
netaustin
Drupal also sends plaintext passwords out of the box (at least in Drupal 6),
although it does hash the password in the database. One of the first things I
do is change the wording of the welcome email.

------
r_kaup
Can someone explain to me why it is so important to hash passwords before
storing them?

~~~
temptemptemp13
The passwords can be stolen and then you royally screwed your users who
trusted you.

[http://blog.moertel.com/articles/2006/12/15/never-store-
pass...](http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-
a-database)

[http://stackoverflow.com/questions/287517/encrypting-
hashing...](http://stackoverflow.com/questions/287517/encrypting-hashing-
plain-text-passwords-in-database)

[http://www.usenix.org/publications/login/2001-11/pdfs/singer...](http://www.usenix.org/publications/login/2001-11/pdfs/singer.pdf)

------
robinwarren
I'd considered doing something like this the other day, good work for getting
the bad news out there! Hopefully this can help lift the expected minimum of
security on the web a little.

------
thisisblurry
I'm shocked that Mozilla not only (seemingly) stores their mailing list
passwords unhashed, but that they also email them out to each member every
month in a reminder email.

------
JCB_K
Reminds me of this: <http://news.ycombinator.com/item?id=2329366>.

Unbelievable.

------
sayemm
Markus Frind did this way back when and suffered for it when Plenty of Fish
got hacked a few months ago, big risk.

------
eekfuh
Toms.com sends you your password after you signup, which is retarded since YOU
JUST entered it into their system.

------
yuvadam
Props! Took me a moment to figure out why all the initial sites are in Hebrew
;)

------
Estragon
A straight list without the irrelevant screenshots would be much more
scalable.

------
treblig
Pretty scary feeling: search your gmail inbox for your default password.

~~~
driverdan
Default password? There's your first problem. Use a utility like LastPass or
1Password. You shouldn't have a default password.

------
code_duck
So, the only companies that do this are in Israel?

------
itistoday
Add Dreamhost to this list.

------
mattmanser
Nitpick, they're not necessarily storing it in plaintext, they may just not be
salting it. There is a difference.

~~~
dansingerman
Whether it is stored plaintext, or in an encrypted format:

1) They are sending it in plaintext

2) Encrypted passwords are a factor less secure than hashed (and salted)
passwords

I am not sure how salting the password comes into it in the context you
describe - can you explain?

~~~
mattmanser
From the site:

 _A website storing a password in plain text means that your password is
there, waiting for someone to come and take it. It doesn’t even matter if
you’ve created the strongest possible password. It’s just there.

...We’re tired of websites abusing our trust and storing our passwords in
plain text, exposing us to danger. Here we put these websites to shame._

That is possibly a libellous allegation. It is not necessarily true.

The password is not necessarily stored in plaintext, it may still be
encrypted.

The website owner does not understand encryption.

Understand my point now?

~~~
JoachimSchipper
There's also a difference between (non-reversible) hashing, with or without
salt, and (reversible) encryption.

Additionally, encrypted passwords are only better than plaintext passwords if
an adversary that breaks into your database does/can not also get the
encryption key. That's unlikely to be the case.

~~~
mattmanser
Very true, my mention of salts seems to have muddied things.

As for getting the key, I'm no Linux expert but in windows afaik SQL injection
generally doesn't allow you to get to the machine key which is used for this
type of encryption.

So it really depends on the attack vector on the likeliness of them having the
key.

I also totally agree in this day and age everyone should be hashing, it's just
too easy to leave an accidental hole and you should mitigate the consequences
of a breach.

But I still stand by the idea that they're not necessarily storing the
password in plaintext, which was all I was trying to say with my nitpick!

~~~
JoachimSchipper
Just look at <http://news.ycombinator.com/item?id=2343330>. Tumblr has piles
of money, and a misplaced 'i' still gave away all their passwords
(fortunately, just their passwords for external APIs...) Keeping the source
code secret is usually not security goal #1, and not needing to is a good
idea.

Also, un-salted encrypted passwords are _still_ bad. Just compare the top 10
most popular encryptions with a table of the top 10 most popular passwords.

I'll drop this, but please do hash your passwords with something sensible like
bcrypt. ;-)

~~~
Dylan16807
Still, you can have your passwords very securely stored in bcrypt AND mail the
plain text out when the account is created. If your email isn't secure that
should really be dealt with, and separately.

~~~
JoachimSchipper
No. E-mail is an unencrypted, unauthenticated protocol; how could sending out
plain text passwords over a plain text protocol ever be a good idea?

------
BrainScraps
The other day I thought there should be a "Wall of Shame" site for photos of
the d-bags who abuse handicapped spots.

~~~
hmemcpy
Just make a tumblr page for it :) Seriously, not including setting up a domain
it takes about 15 minutes...

~~~
nickbarnwell
>not including setting up a domain it takes about 15 minutes...

Which, coincidentally, is about the same amount of time as you can expect your
tumblr page to be up every month ;)

