
Passwords in plain text - solray
http://plaintextoffenders.com/
======
omervk
Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO.
Always a pleasure to be featured on the front page of HN.

You're welcome to ask me questions, though we've covered most on our about
page
([http://plaintextoffenders.com/about](http://plaintextoffenders.com/about)).
The one we haven't is usually "Is there an API/better search/new site coming?"
to which the answer is that we're both doing this in our spare time and though
we really want to create something better to host this very important content,
we can't spare the time. If you've got time and want to volunteer to create
this new site, please let me know. :)

~~~
hmemcpy
Hi, I'm @hmemcpy, @omervk's partner in crim^H^H^Hplaintextoffending :)

One of Such Volunteers (wow!) made a Chrome Extension that scrapes addresses
from PTO and shows you a red banner if you're on a site that's featured PTO!

[https://chrome.google.com/webstore/detail/plain-text-
offende...](https://chrome.google.com/webstore/detail/plain-text-offenders-
aler/ggndaknbenjhnkddgjnjjcmomgaidhmd)

~~~
Monkeyget
Apparently the list of offending sites is hardcoded in the extension (
[https://github.com/klinskyc/PTOAlert/blob/master/sites.json](https://github.com/klinskyc/PTOAlert/blob/master/sites.json)
) and the extension is not updated to reflect changes on the sites.

------
Monkeyget
The case where you get your new password by mail when you just changed it does
not necessarily mean it is stored in plain text. They could keep it around in
memory just long enough to send it by mail.

Doesn't mean it is a good idea though.

~~~
pjscott
There _are_ some ways to do that sort of thing safely, for some value of
'safe', but they're non-trivial. Sticking the plaintext passwords in a
database row is trivial. Which do you think is more common? :-(

~~~
fooyc
That's really trivial, and many web applications work this way:

    
    
        email = input.email
        plainPassword = input.password
    
        hashed = hash(plainPassword)
        saveToDb(email, hashed)
    
        sendGreetingEmail(email, plainPassword)
    

Emailing a plain text password during registration is not the same as storing
it forever in a database.

~~~
uulbiy
It's not the same but there are other security issues. The server to server
transfer of the email message might not be encrypted (it might be if _both_
have TLS extensions enabled). So, emailing plain text passwords is always a
bad idea even if it's not stored as such.

~~~
fooyc
I agree that from a security standpoint it's better not to send the password
in plain text at all.

But then you can start listing non-HTTPS sites, too. You disclose your
password in plaintext to many servers every time you login on those.

~~~
jonahx
Those _should_ be listed too. I'm not sure I follow your point: Because there
exists this other really bad but common practice, why are we harping on this
bad practice?

~~~
hackinthebochs
Being overly concerned about having your email sniffed as its passed along
internet peer is just misplaced anxiety. Anyone who can successfully sniff
your password from your email in transit can already own if they chose to. The
convenience factor of having your password emailed and having a record of it
in many cases trumps this concern.

"But what if someone hacks your email, they know all your passwords!"

What if someone hacks your 1password account? It's the same exact scenario.
Having a single point of failure that one can be extra vigilant with guarding
is much better than the alternative of having a hundred unique passwords one
must remember.

~~~
jonahx
Re: your 1password vs email point, while they might both be single points of
failure, in practice one's email is usually more vulnerable. Boyfriends,
girlfriends, friends, etc, have occasional or accidental access to email for
whatever reason (Bosco!). Especially on a smartphone. This kind of thing is
much less likely, though of course still possible, for password managers. I
don't know about 1password in particular, but the one I use has a 15 minute of
inactivity (or upon sleep) timeout before the master pw is required again. The
iPhone version requires a pin any time it loses and regains focus. And you can
customize the settings to alleviate pretty much any level of paranoia.

------
jzelinskie
Scrape all the URLs from that website. Then write a browser extension that
looks up the current tab's URL and turns red if it matches one of those
domains. Use PRs to manage addition/subtraction of offenders to the list. Now
even grandma knows when a website doesn't save your password safely and
shaming them will have more impact.

~~~
hhariri
There's already a Chrome Extension for it if I'm not mistaken.

~~~
gkcgautam
Can you share the name or link please?

~~~
switch007
From a comment further down [https://chrome.google.com/webstore/detail/plain-
text-offende...](https://chrome.google.com/webstore/detail/plain-text-
offenders-aler/ggndaknbenjhnkddgjnjjcmomgaidhmd)

------
HarrietJones
A lot of talk of passwording concentrates on threats at the technology end,
and they ignore threats at the user end.

Emailed Passwords are a failure from a tech point of view, but they allow
users to create more complex passwords without punishing them when they forget
that password.

As it is, I have situations now when the complexity requirements of a password
combined with the fact that I need to sign in to a separate mobile App and I'm
given no way of seeing what the password was when I created it that I just
throw my metaphorical hands in the air, and reset it to generic password
"Green!12Letmein." on yet _another_ account.

This is _wrong_ of me. I know it's wrong, I'm aware of password remembering
services and I'm technical but I still do it.

If I'm doing this, and you're doing this, then most of the world is doing it.
By discounting passwords sent through email, then we may be making overall
security worse instead of better.

~~~
x1798DE
There's no point in using a secure password if it's stored in plaintext.
Brute-force attacks on passwords usually need to be done offline in order to
be effective (unless the site happens to not throttle authentication queries),
so essentially as long as your password isn't one of the attackers' first
100-1000 guesses (being extremely charitable here), then it doesn't matter if
your password is 15 characters or 150 characters, because the primary attack
vector (database compromise) will reveal it instantly.

Additionally, allowing passwords to be e-mailed is even _worse_ than this,
because there's a good chance the password is not encrypted in transit, which
means that it can be intercepted on the way to your mailbox. In that case, the
attacker doesn't even need to compromise the database to get your password, no
matter _how_ complex it is. Storing passwords in plaintext removes security
even if it makes people use less complicated passwords.

------
drinchev
As far as I can remember HN also ( not a long time ago ) was giving plain text
passwords. I'm glad this was discontinued and proper recovery password email
is sent now.

[http://i.imgur.com/sDt0DVK.png](http://i.imgur.com/sDt0DVK.png)

------
mrcdima
But how does one handle password resets without resorting in one form or
another to sending some info in plain text to users?

At least one website on the current front page is there because it sent a
temporary password in plain text. I assume this happened because the user
forgot his password. This says nothing about how they store passwords and
after all how else would you handle a password reset? Send a password reset
link? That's the same thing.

Sending passwords in plaintext back to the user after he has set/changed his
password is clearly a security risk but when it comes to temporary passwords
or password resets how else would that info be sent?

~~~
p8952
You should be sending a token and/or reset link which will allow the user to
choose a new password.

This is much better than just sending a new password because:

* It can have a TTL.

* The user has to change it, they can't just keep using the plaintext one forever.

* You can perform some kind of verification, was the request for a new password sent from the same country/IP/device as the person generating a new password.

~~~
mrcdima
But can't you implement all three with a temporary password as well? Make the
password valid for 24 hours only and when the user logs in with their
temporary password perform any kind of extra verification and if that's passed
then also force the user to change their password. Seems like the same thing.

The website I noticed on the front page (sunsuper.com.au) was doing precisely
this (although their TTL was 90 days which is indeed far too long and it's
impossible to tell whether they forced a password reset or simply recommended
a password change).

~~~
jeltz
Yes, but using a token is better for usability and trust since that wont make
it possible to lock out other users by clicking the forgot password link, and
I as a user will think it is more likely someone doing token based resets has
done security correctly.

------
vijayaggarwal
We already have a fairly good solution to this problem in OAuth. However,
current popular implementations of OAuth are third-party owned which is not
desirable for many reasons (for example, google won't use facebook owned
OAuth, and vice-versa).

Ideally, we should have a self-owned OAuth service implemented by browsers or
operating systems. And the APIs of this service should be standardized. Also,
the storage should be locally available with remote sync optionally available
for backup and cross-device syncing.

~~~
Excavator
Something like the Firefox Accounts¹ project? Which has Oauth2 support² in the
works.

1:
[https://wiki.mozilla.org/Identity/Firefox_Accounts](https://wiki.mozilla.org/Identity/Firefox_Accounts)

2: [https://github.com/mozilla/fxa-oauth-
server](https://github.com/mozilla/fxa-oauth-server)

~~~
vijayaggarwal
FxA is primarily for Firefox's own products and services. Mozilla Persona
(confusing name - personas is what they called firefox themes as well) is
closer.

~~~
Excavator
Yea but there's really no good docs for Persona around anymore, that I can
find.

The plan is to use Persona for ones FxA:

> One we get the basics down and enable single sign-on for relying Mozilla
> Services with your Firefox Account, we hope integrate Firefox Accounts with
> Persona on the Web and Firefox user agents to make logging in everywhere as
> painless as it should be.

------
astazangasta
Why are we still doing this? We've known how to do secure authentication
without the remote end holding your secret for years via public keys. Everyone
here likely does this every day with ssh. There is even a browser mechanism
for generating personal certificates for web authentication. The correct long
term solution to this ought to be making this solution more intelligible and
accessible to users. To hell with passwords and password exchange. They are a
huge bug on the internet.

------
nly
Used a sportsbook a few years ago where the popup to view and update your
account details, which had a hidden address bar in most browsers, contained
"password=<yourpassword>" in the query string. I reported it but they assured
me they were 'using encryption' and to look for the 'lock in my browser'. They
were using SSL, but had no clue. The site probably handled millions of $ a
week.

------
oakwhiz
I wish websites would actually use client certificate authentication instead
of having to play hot potato with secret passwords.

~~~
ddebernardy
This a thousand times. And ssh keys for servers.

But then, how would you log into e.g. gmail from a cybercoffee in a foreign
country? (Assuming you dare do so in spite of the risk of key loggers.)

~~~
scott_karana
> But then, how would you log into e.g. gmail from a cybercoffee in a foreign
> country? (Assuming you dare do so in spite of the risk of key loggers.)

This still applies with any other authentication schemes...

------
golem_de
I say just mailman.

Anyone from Mozilla, EcmaScript, GnuPG and thelike here? Don't miss your
monthly "password reminder" mail...

P.S. Just save ONLY a salted hash. Hash functions are designed to be one-way,
so no one but you can re-store your password. EVER.

~~~
mnemonik
I filed a bug and it was closed waiting for mailman 3 to ship :-/

------
imrehg
I've been just thinking about this after receiving 2 such emails in one day
this week. Submitted both to the archive, thanks so much for doing this!

Name and shame, that's the minimum to make them change.

------
bato
The scariest part is that there are 200+ pages of those...

------
yeukhon
The worst is list running mailman that actually sends monthly password
reminder. Is the new GNU mailman still shipped with such reminder feature?

------
borplk
Just use a unique password every time and rest easy.

~~~
omervk
99.99% of people won't do that. We're trying to make the Internet safer for
them.

------
Myrannas
Its a little scary how big that list is.

My concern is that this is a great source of websites with poor security for
potential hackers to exploit.

~~~
ytch
That's why we should use different passwords on each website

~~~
fredsted
Thankfully password managers and software like iCloud makes this extremely
easy. There's no excuse to not do it!

------
based2
[http://www.theregister.co.uk/2014/06/20/32000_motherboards_s...](http://www.theregister.co.uk/2014/06/20/32000_motherboards_spit_passwords_in_cleartext/)

------
wereHamster
usenetbucket.com

Usenet provider

Forgot password asks you to type a password, in which it instantly emails back
to you in plaintext.

Doesn't mean it _stores_ it in plaintext.

~~~
pandler
It seems that most of these just send you your password as confirmation (or a
temp one after requesting password recovery). Even assuming the best case
scenario that these are just password confirmation emails, it still bothers me
that my password would now be in my email as plaintext.

------
salimane
digitalocean.com stored your password in plaintext!!!

~~~
jivid
I am a Digital Ocean customer and the only password they've ever emailed me is
the root password for the server I just bought. Arguably this isn't as safe as
AWS' process of making you download a kaypair and only letting you login with
that. However, VPS owners should get in the habit of logging on to any server
they buy and immediately disabling password auth and root login via SSH, which
helps negate the root password being sent over email issue to a certain
extent.

~~~
jackalope
How is downloading a key pair generated by someone else safer? If this is only
for login purposes (I don't use AWS, so maybe there is another reason), you
should generate your own key pair and send them only your public key (which
doesn't require an encrypted transfer, BTW). If AWS knows your private key and
can view it or provide it to you at anytime, that's no different than storing
passwords in plaintext.

~~~
jivid
The keypair AWS generates can only be downloaded once, at the time of instance
creation. Beyond that, they expect you to be in possession of the keypair when
launching another instance that uses the same keypair. If you happen to lose
the file, you're basically out of luck.

So to directly address your concern, you can't download the keypair at any
point in time, it's just a one time thing. To me that seems much more secure
than emailing out a root password and enabling password authentication by
default.

~~~
aianus
I much prefer DigitalOcean's option of no root password and letting me upload
my public key. There's no need for them ever to know my password or private
key.

------
johnsteve
It does not seem safe or anything...

------
Daiz
Should really start doing this for sites using MD5/SHA1 for password hashing
too, as using them is barely above plain text in terms of security these days.

~~~
TomGullen
> as using them is barely above plain text in terms of security these days

How so?

~~~
Daiz
Cracking them is so fast these days that they don't offer much in terms of
security. For example, take a look at this post:

[http://www.troyhunt.com/2012/06/our-password-hashing-has-
no-...](http://www.troyhunt.com/2012/06/our-password-hashing-has-no-
clothes.html)

Then note that it was posted _two years ago_. GPUs surely haven't gotten any
slower since then.

~~~
TomGullen
Same applies to all hash functions. It's how you implement it that counts.

