
 Pingdom is storing passwords in plaintext - seldo
http://seldo.tumblr.com/post/8698245004/dear-pingdom-you-should-not-be-storing-my
======
IgorPartola
Shameless plug/seizing the moment: Ping Brigade
(<https://www.pingbrigade.com/>) does everything over HTTPS, stores passwords
using bcrypt and never emails them to you.

Moreover, because I really love HN, I'm going to run a 50% off discount at
<https://www.pingbrigade.com/signup/hn>.

Edit: Wow, that was a quick downvote. Just wondering since when is building a
better product than the giant of the industry and showing it off on HN compels
people to click the downvote button?

~~~
decadentcactus
I think some will consider it a _bit_ unnecessary. I upvoted you, gotta seize
those moments when they come :)

~~~
IgorPartola
Thank you :)

------
ddlatham
They are not necessarily storing the password in plaintext. However, they are:

1\. Storing it in a recoverable format, instead of a format that only allows
verification.

2\. Emailing them in plain text.

Both of which are bad.

~~~
shubber
Just to be clear: there is no significant difference between either of these
and simply storing in plaintext.

"In a recoverable form" means that a) there's a single key with which to
decrypt the passwords. If I can get the password list, the key isn't far away.
And it might not be worth the effort to track it down, since it's practically
equivalent to have the (two-way) encrypted passwords and to have the
plaintext.

~~~
pbreit
Yes, there is.

In most companies, the database is significantly more accessible than any
encryption keys. For goodness sake, marketers typically have query access to
the DB.

And the issue of emailing a password is different. The problem there is that
if I gain access to your email account, I can quickly search "password" to
discover your private passwords that a company, not you, chose to drop into
your email account.

But to be clear, user-created passwords should be stored one-way hashed and
never emailed.

~~~
AgentConundrum
> _For goodness sake, marketers typically have query access to the DB._

That's a bit of a straw man, don't you think? Even if marketers have access to
the database, they shouldn't have read access to the passwords table in a
properly configured system. If they do, it's time to fire your DBA.

> _The problem there is that if I gain access to your email account, I can
> quickly search "password" to discover your private passwords_

Sometimes it's worse than that. I recently had to do a password recovery on a
site, and they sent the password not only in plain text but also as the very
beginning of the email. As such, gmail helpfully showed "example.com" as the
sender, with "Password: _P@ssword1_ " right in the body preview snippet. You
could see it without even having to open the email.

It may not be a common exploit, but if I was checking my gmail at work, a
coworker that knew I had an account on this website could just send a recovery
request and glance over my shoulder at just the right time and grab my
password without my knowledge. Not good.

I wish Google would implement some sort of algorithm that could determine
password-looking text and a) not show it in the preview, and b) require user
interaction to display it when viewing the actual email body.

~~~
danielharan
The odds of having a properly configured database in a company that stores
password in the clear don't seem very high.

------
bdhe
Obligatory link for those who haven't seen it before but want to know the
right way to do it. <http://codahale.com/how-to-safely-store-a-password/>

~~~
delano
We implemented this (bcrypt) for <https://www.blamestella.com/> (a web
monitoring service for devs and designers)

~~~
rwolf
Your use of the word "implemented" gives me pause. I hope you mean "We've
plugged the standard bcrypt library into our web app." and not "We found a pdf
describing bcrypt on the internet and one of our 'rockstar ninja warlock' devs
stayed up for a week writing an implementation that no one else is using and
no one has reviewed."

~~~
delano
Ah yes, of course we didn't implement our own bcrypt!

------
cookiecaper
As we see from this thread, people really need to stop assuming that a site
will store their password securely. Find a system that allows you to use a
unique, random password for each site and use that instead. Do not trust any
site to store your password in a secure fashion as relatively few actually do.
If someone can get into the password database on a site, it probably doesn't
matter if they have your password or not, because they can usually still
access everything directly anyway by looking up your user id and performing
the relevant queries.

The danger in plaintext storage is that your password to other valuable sites
may be exposed by a leaked database dump or similar. This is not a concern if
you use a randomly-generated unique password for each site you visit.

Everything is just much safer this way. With some companies making kind of
legitimate arguments for plaintext password storage, just assume that your
password is NEVER secret to the admins of a site or anyone who may break in
and steal their information. Things would be much nicer for everyone involved
if we did this.

There are systems in place that make this pretty easy. Personally I use a
home-grown method: pwgen -c xx, copy and paste the coolest-looking password
displayed, email to myself encrypted, and decrypt with my secret key and copy
and paste any time I want to use a site. There are also things like LastPass,
KeePass, websites that generate hashes of passwords salted with another phrase
or target site URL (copy and paste final output), websites that output a
simple character lookup table based on a user phrase, etc. I believe that an
interested party could make one of these things work well enough for use among
the general people (especially with automated sync platforms from Google and
Mozilla). We need to stop relying on anonymous third parties for our personal
safety.

~~~
16s
I encourage people to use SHA1_Pass. I wrote it and provide full source code
under the GPL license. It's free as in freedom and beer. I use it because (as
you stated) sites don't do the right thing and have other priorities.

As conscientious users and devs, we have to take matters into our own hands.

------
fourk
It would be nice if there existed a browser extension that would warn the user
anytime they are about to register on a site with password storage issues like
this. Of course, there would need to be some sort of community maintained
repository for tracking which sites are doing this.

~~~
gst
Why should it warn the user?

Either the user is using the same password on multiple sites. Then this would
be a real security issue, independent of the fact if some of the sites store
the password in plaintext.

Or the user is using different passwords for different sites. Then you don't
really need to care how a single site handles your password.

~~~
ddlatham
One reason is that if they are storing the password in a recoverable format,
it tells you something about how much you can trust the security of that site
in other ways. Even if you're using a different password, you may be much more
hesitant about what other information you are willing to put into a site that
doesn't take security seriously.

------
ck2
One of many that might surprise you: <http://plaintextoffenders.com>

~~~
coin
How do you know the "offenders" are storing in plaintext?

~~~
johnx123-up
The _detection_ process is somewhat wrong. In many sites, they store passwords
in plaintext or reversible plaintext--but they send mere link to reset. So,
you don't _really_ know, how they're storing. IMHO, most of new startups store
passwords for the sake of _learning_. Definitely, there needs to be some
disclosure on how they'll store passwords.

------
BrandonDC
Password security is a shared responsibility between the company storing the
password and the user who chooses what password to store. As a user, you
rarely know the full extent to how a company manages the storage of passwords
so the responsibility truly rests on your shoulders to choose unique passwords
for each service that you use.

~~~
dpark
This is simply not realistic. I've got hundreds of accounts online. I cannot
remember a truly unique password for each. It's not possible (not for me at
least). I can't even remember all the sites I've got accounts.

A lot of people implement their own hash ("I use a base password plus the
second letter of the url and the number of letters in the domain: dumbe18"),
but this is not unique per site, and these hashing schemes don't tend to be as
unique or as hard to figure out as one might imagine.

There are utilities now that try to help, but I've not found one that's even
remotely convenient when it comes to accessing sites on multiple computers, my
phone, and my tablet. Not to mention I'm putting my trust in a 3rd party to
handle all of my passwords when I do this.

~~~
cpeterso
I use the _SuperGenPass_ Password Generator bookmarklet. It generates site-
specific passwords by hashing the site's domain name with your master
password. You can save bookmarklet offline or host in on your own web server
so you can generate passwords when you are away from your home computer.

<http://supergenpass.com/>

The only problem is when SuperGenPass's generated passwords are not compatible
with some site's unusual password restrictions. They I have write down a one-
off password. A cool idea: a password generator bookmarklet that knows the
site-specific password formats. The formats could be extensible (by
bookmarklet developer and end users), analyze HTML5 form validation rules, or
websites could publish a machine-readable password description microformat.

~~~
dchest
_SuperGenPass uses a one-way hash algorithm (base-64 MD5) to generate
passwords._

Bah.

Here's mine
[https://chrome.google.com/webstore/detail/hegbhhpocfhlnjmemk...](https://chrome.google.com/webstore/detail/hegbhhpocfhlnjmemkibgibljklhlfco)

------
juiceandjuice
Also...

Equifax also stores your password in plain text.

~~~
cpeterso
[citation needed]

~~~
juiceandjuice
I hope it wasn't you that downvoted me.

<http://news.ycombinator.com/item?id=2865719>

You'll have to take my word I think though... the password blacked out is my
password.

~~~
cpeterso
Wasn't me. I figured it must be true; I just wanted to learn more. :)

------
hm2k
Your bank stores passwords in plain text, but then they never email it to you.

~~~
feydr
_some_ do like discover.com (unfortuantely) truncates your password at 8
characters, downcases, and sends you in plain txt email

~~~
gst
That's what I don't understand about banks.

On 99% of all websites I can use special characters in my passwords. The only
exception are my online banking sites, where I'm forced to restrict myself to
[\d\w] one one of the sites and to [\d] on the other site.

~~~
dennisgorelik
Government's security regulations that banks must follow make banks less
agile. That in turn make banks security system weaker.

These are unfortunate unintended consequences.

------
drewjoh
LiquidWeb also does this from my experience. Sign-up for a new account and
have them call you for verification. Their verification question is "What is
your password?".

------
j15e
Told you so a year ago : <http://news.ycombinator.com/item?id=1118012>

------
ErikRogneby
crunchbase has a nice list of competitors:
<http://www.crunchbase.com/company/pingdom> Watchmouse appears to have some
pretty high end customers. (including twitter, AT&T and verisign )

------
lurkinggrue
They brute force attack your password hash and then mail it to you.

------
jfong
This probably happens more than we think.

------
funkah
Emailing the password is bad and they should stop, but where is the evidence
that they are storing the password in plaintext?

~~~
dpark
The fact that they sent it in an email in response to a user request means
that they are at least storing it in a reversible format. Given that they sent
the password in plaintext via email, I see no reason to believe they are
competent enough to set up a reversible system that is more secure than
plaintext (e.g. rot13 isn't more secure but isn't technically plaintext;
storing an encrypted password with the key isn't more secure). In all
likelihood, they are storing in plaintext or an equivalent.

~~~
coin
reversible != plaintext

~~~
dpark
Could you not be bothered to read my comment before replying?

------
tbeseda
You can remove your account from the Subscription page of your account.

~~~
fourk
Is there any guarantee that this actually entirely removes your data from
their databases? How do you know they don't just toggle an `active` column for
your row in the users table?

------
ErikRogneby
I'd like to see these questions added standard to VC pitch meetings:

1)How do you store passwords in your datastore? plaintext?

2)When users login to your service and provide their credentials is it over
SSL?

~~~
fourk
I'd be interested in seeing the correlation between return on investment and
level of basic security-related competence at the point at which the company
first attempted to raise VC money.

~~~
tptacek
It's probably negative. A dollar spent on security is a dollar not spent on
customer acquisition. Don't put security in your slide deck.

