
Hover.com: we store & email passwords in plaintext for usability - MattHampel
http://help.hover.com/2011/04/21/feedback-fuels-features-what-we-have-coming-up/
======
markbao
This isn't a microblogging service or pet social network. A domain registrar
is storing your password in plaintext? Really? Didn't we go over this a
thousand times?

If I was on Hover (which I considered), I'd transfer my domains immediately.
Moving to a plaintext password system to get fewer support requests is like
removing the door from your house so you don't have to keep fumbling for the
key.

~~~
mishmash
After some positive research, I just purchased two domains from Hover. This is
unacceptable however and I will be moving them away.

What registrar would anyone say is the most security focused and/or government
resistant?

Maybe it should be a 2011 AskHN?

~~~
AdamGibbins
I can't vouch for "security focused" - but Gandi.net have so far never let me
down. They're based in France, so not susceptible to US law (dependent on the
TLD you use of course) and have a huge variety of TLDs.

Can't recommend Gandi enough, they do exactly what they say on the tin - "no
bullshit".

~~~
jarin
Gandi is pretty awesome, but just be aware that your credit card company might
freeze your card the first time you buy from them (apparently buying domain
names in other countries is a fraud trigger) :D

~~~
Maxious
Never had that problem with Gandi but buying digital goods from Facebook froze
my card. Apparently they were a hive for credit card thief testing at that
point in time because of the low value of virtual gifts (1 US cent?).

------
geuis
I've considered using Hover and switching away from Godaddy, particularly
since Hover is recommended frequently on the TWiT network. That thought has
instantly evaporated.

You absolutely cannot store passwords in plain text. There is no level of
security you can wrap around the database that will ever be 100%. It only
takes one mistake for _everything_ to get exposed.

To try and reason that there is a trade off between customer support and
security is ludicrous. Your reset emails aren't getting through? Work on
fixing that damn system instead of exposing your customers to a world of hurt
down the road.

~~~
xorglorb
DreamHost also stores passwords in a recoverable fashion, FYI.

~~~
masterzora
Disclaimer: I am an ex-DH intern and my information is only as good as August
2010, but it is likely to still be accurate.

At the very least, DH does not store passwords as plaintext, but it's only
very marginally better than that. Passwords are stored using a custom-rolled
symmetric encryption algorithm created by... I never found out if it was a
founder or just one of the earlier admins, but that doesn't really change
much. For what it's worth, I never ran across the key to this, which is at
least somewhat good in terms of security, but it's quite possible that this is
true only because I never actually went searching for it, especially given
that all of the devs and dev interns have root on most of the systems.

~~~
boot13
I can confirm that they're still doing this. I recently had a conversation
with their support staff about it and I don't think they'll be changing it any
time soon. I like Dreamhost, but if they don't change this I'll probably bail.

~~~
Dylan16807
Can you explain why you would leave over that? As long as you are aware of it
and use a unique password how does it impact you? They would have to have a
very specific and unnoticed breach that gets database and key.

Is it worry that they are lax in security elsewhere?

~~~
masterzora
I'm not one such person (although I've never used DH's services for other
reasons, even while I was employed by such), but I could imagine a reasonable
person saying "if they take part in bad practice X of which I know, what other
bad practices might they take part in of which I don't know?"

------
raganwald
Blaming Hover.com is shooting the messenger. The problem here is that _this is
what customers want_. As long as you ask Hover to compete for business in a
race to the bottom of the "convenience" barrel, you are going to have this
problem. If Hover stop doing this, someone else wil come along and take
Hover's business by sending plaintext passwords around in email.

So.

You either live with it and do your business with someone who has decided to
offer a "premium" service and has a business model catering to educated
customers,

Or:

You look for the government to regulate the marketplace as a public good. We
do this with things like the safety of cars, we've decided that the
marketplace cannot be left to decide this for itself. We attempt to do this
with things like the content and handling of food, we've decided that the
marketplace cannot be left to decide this for itself.

Perhaps the security of your account is not important enough to impose
regulation. Perhaps it is. But as long as it's left up to the marketplace, the
existence of companies like Hover is inevitable, and waggling our fingers at
them is not going to do anything except make us feel smarter than the average
bear.

~~~
mquander
It's not what customers want! Customers don't have a clue. They trust the
provider to look out for their interests, since they are not experts.
Customers don't understand that receiving a password instead of a reset link
means that someone else can take their password. Customers don't know that
probably any technical 16-year-old who doesn't like them (or any Hover
employee) can figure out a way to break into Hover.com and steal their
account. Hover is taking advantage of their knowledge to exploit the ignorance
of customers.

I agree that we probably can't stop them from doing it short of government
regulation, but that doesn't mean it's not a fucked-up thing to do.

~~~
gregory80
Second! Customers do not want insecurity. That's like saying people want bank
vaults with glass walls. It's ridiculous on its face.

------
eam
> _Very quickly, our customer service team was inundated by requests from
> people that weren’t receiving the email, found the process confusing, and a
> myriad of other related requests._

Wait a second, so customers wont receive an email with a password reset link,
yet they'll receive an email with a plain text password? I guess it's
possible, but interesting.

~~~
kgermino
It's not that they don't get the email so much as they don't understand it.
Where I work, I make a new account for someone, then send them a password
reset email asking them to create a password for themselves, and a personal
email writteden by me explaining exactly what they need to do (go to this
other email, click the link, enter your new password twice, hit enter, then
log in) and I still have 1 in 4 result in support requests. Usually along the
lines of "I don't know how to log in because I don't know what my password
is.".

~~~
pavel_lishin
> It's not that they don't get the email so much as they don't understand it.

Wouldn't hiring a writer and a designer for a day to re-design the e-mail so
that it's more obvious and easy to understand be a better solution than
storing passwords in plain text?

------
arihant
"Very quickly, our customer service team was inundated by requests from people
that weren’t receiving the email, found the process confusing, and a myriad of
other related requests. "

What I read - Because we aren't smart enough to create an automated password
recovery that works, you should now trust that we are smart enough in network
security to safeguard your passwords.

Also, these guys mention that they were receiving multiple requests. But how
many requests came per user? If you got a million users and they each forget
their passwords once a year and have to spend 5-10 minutes resetting it, I
don't think its a usability problem at all, even if I get 1 million mails a
year complaining about it. Its a bad decision for company handling domains and
credit cards. And even if these guys really are good enough to secure their
end of systems, whats the guarantee that my inbox is not compromised?

~~~
pavel_lishin
Ten million minutes is approximately nineteen years. That might indeed be a
usability problem.

------
naner
This really isn't that uncommon. When forced to choose between easier customer
support or ostensibly better security practices, easier customer support
usually wins. Stolen passwords through email/eavesdropping are rare enough
that they can deal with it on a case-by-case basis. If someone somehow gets
access to the entire database of passwords (also rare) then they have other
security issues that likely would have been a problem no matter how they
stored passwords.

If company X hashes your password on their server you still don't know that
they did it properly or how good the rest of their security is. Basically the
only way this differs is that you when you forget your password, your actual
password sent in plaintext over the network and is now sitting in your email
account. That makes me uncomfortable so I change it right away. Which is the
exact same set of steps you would use for a hashed password reset.

Everybody focuses on the hashing thing like it is some kind of impenetrable
defense or crystal ball into a company's security practices. It is not.

~~~
pavpanchekha
You miss the problem --- it's not that hackers get access to your Hover
password. It's that for most people, they get access to all of their other
passwords, since they're all the same. Also, stealing Hover passwords by
wiresniffing must be done on a case-by-case basis, or at least by small
geographic neighborhood; stealing them via a database dump can be done en
mass.

------
pittsburgh
_In the past few weeks, we’ve discussed a new approach that we think will
strike a better balance by giving our customers greater control over password
management and at the same time ensuring the basic security of those
passwords. I’m personally very pleased that our approach will have appeal to
customers that are concerned about password security and customers that
appreciate the benefits of great usability (and for customers who are
concerned about both, blow their socks off_

Could anybody find the blog post they are referring to that explains their
balance between simplicity and security? I was unable to. However, it does
appear that they still send plaintext passwords via email:
<https://www.hover.com/send_password>

If you're looking to switch registrars, I can't say enough good things about
<http://gandi.net>. Their motto is literally "no bullshit" and it's the reason
I switched to them a few years ago. They aren't the cheapest option, but their
UI is very simple and aesthetically pleasing, they offer free DNS hosting,
they don't clutter their checkout pages with any ads or ridiculous upsells,
they don't kill elephants for fun ( <http://mashable.com/2011/04/01/bob-
parsons-elephant-story/> ), and they don't email your password in plaintext.
There are very few companies I'm willing to rave about, but Gandi is one of
them.

~~~
SkyMarshal
Second all of that about Gandi. They also seem to offer more TLD's than most
of the mainstream US-based registrars.

------
wccrawford
Maybe this is all an elaborate practical joke.

Or maybe they wanted to test their security, so they're putting out an all-
call to every blackhat out there.

Because either of those makes a lot more sense than what they've said.

------
alexmuller
I emailed them about this a few months ago after being spurred on by the
creation of plaintextoffenders.com:

> I received this email when I registered with you last year, and was prompted
> by the recent creation of the site 'Plain Text Offenders' to send it to
> them. Somebody else has submitted their registration email too:

The reply was as follows:

> We realized that this area was of great concern to many customers and we
> have since removed password submission in our 'Welcome' email.

So to give their customers peace of mind, they made it less obvious that what
they're doing is stupid.

------
joshontheweb
W T F. I just opened an account with them. Im not too happy. Always seems
disrespectful of companies to do that. I think they should at least inform you
before you make the account that they are sacrificing your privacy and
security in order to cut down on customer service requests.

------
rkudeshi
Whenever I call up MediaTemple for support, they always ask me my password for
verification. Does that mean they also store passwords in plaintext? (serious
question)

~~~
eftpotrm
Not necessarily, they could in theory be entering your password into their
computer and seeing if it matches the hash, exactly as if you logged in. But,
if they're asking for you to read your password to their call centre down the
phone, I'd be surprised if they were that savvy.

~~~
aquark
I'm not sure it follows that reading the password down the phone is a bad idea
... unless you are calling because you have forgotten it!

My bank has a separate passphrase that I have to use on the phone and I call
them rarely enough that remembering it is always a challenge. Asking for my
mother's maiden name can hardly be considered secret anymore, and remembering
the answers to other security questions is a pain: what did I claim was my
favourite movie a year ago?

If I've called them I don't really have a problem reading my password to them.
If I don't trust the call center staff I can always change it afterwards.

~~~
eftpotrm
If you're reading it down the phone then you're revealing your login secret to
an insecure third party and potentially providing them with the means to log
in as you.

------
macmac
"Sorry sir, we really don't know how much money is suppose to be in your
account. Our developers thought that transactions added too much overhead, so
they decided to drop them to insure that the increased response time wouldn't
anoy our customers."

------
JohnsonB
Couldn't they at least encrypt it, and store the key on a separate file?

*edit: I just want to be clear, I don't actually think encryption would a sufficient replacement for a good hashing function, the question was just pointing out how bad this decision by Hover was; not only do they decide to make the password recoverable, but they don't even take whatever meager opportunities there are to make it at least somewhat secure.

~~~
ori_b
What good would that do? If an attacker gets in, they can get the key just as
easily as they can get the database.

~~~
HaloZero
But if you encrypt it with a key, then SQL injection attacks can't collect
passwords as easily. You need to hack in and get the actual key to decrypt.

------
scottkrager
At least they make a case for it. Security isn't just how you store passwords.

~~~
politician
Personally, I've decided to take the position that password security is the
"canary in the coalmine" of a business's awareness about security concerns.
The degree to which they aren't protecting user passwords correctly likely
predicts the degree to which they aren't aware of SQL injection or XSS
vulnerabilities.

~~~
scottkrager
That's a very good point.

------
freejack
tl;dr: guy from hover, mea culpa, new code on the way.

I thought it might help to provide some further deets on that blog post.

I don't think we're making a case there, or providing an excuse - it certainly
wasn't my intent to try and convince anyone of anything when I wrote that, but
rather, it was an exercise to explain where we were (with that and other
development projects) and where we were going.

We've gone back and forth on how we handle passwords over the years - and it
has always come down to what type of interaction do we think will be best for
our customers. I haven't re-read that post from April today, but I think I
mentioned our last go-round on this made it much easier for our customers and
customer service people to help in bound callers and sacrificed too much in
terms of security.

We'll probably continue to go back and forth iterating the implementation,
each time narrowing the swing of the pendulum until we find something that
more appropriately balances what we think our customers are looking for in
terms of security and usability.

I'd also like to point out that the scope of the risk isn't trivial. For
example, URL-based password resets are only as secure as the mailbox they are
sent to. i.e. a significant number of domains are stolen and threatened to be
stolen through email account exploits (re-registering previously used
addresses, forwarding attacks, etc.) This is made even more complex when a
domain expires and email on that domain stops functioning. Where should the
password reset go? We get dozens and dozens of calls a day from people in this
position that need our assistance, making it tough to simply send out a reset
request.

Anyways, I didn't come here to make excuses, I just thought I should
acknowledge that we're aware of the gap (we caused it!) and working on it and
considering the whole set of variables. Security is our primary consideration
but that doesn't give us the luxury of ignoring the usability implications.
Were that the case, we'd simply issue two-factor fobs to our clients and be
done with it.

And finally, to those of you that guess at some sort of evil corporate motive
or the involvement of stupid engineers, or even just dangling the implication
that we've "Made a Final Decision" to store passwords this way, etc. It just
isn't the case - our engineers are great and our motives are pure. If you want
to blame anyone specifically, you can blame me for pushing the implementation
in the direction I did. We're really just trying to do the right thing for our
clients, and in this case, I took a great idea too far. Its just code, it can
be changed - it will be changed, and changed in a way that will help our
customer service staff continue to provide awesome customer service and also
enhance the protection of our customers assets without stepping on toes in
either regard.

We originally posted that commentary back in April because we had a ton of
work backed up behind the release of our new domain and email management tools
- which included a huge refactoring of most of the core code, transitioning to
TDD and a ton of other important pieces. We were supposed to be done work on
those pieces months ago, but as the management tools took shape, the task grew
longer, pushing out these items to the point where it was getting embarrassing
with our customers. That work shipped late last month and launches formally
tomorrow putting us back in a place where we can get serious about the
backlog. The new approach is pretty straightforward and moves us to a hashed
password file, URL-based resets, etc. but also some identity verification
features that our customers and customer support staff can use to validate who
they are talking to in order to force resets manually. Its the validation
piece that I'm most excited about given the extent to which the bad guys will
go to phish a user out of their creds. We've seen some pretty sophisticated
social engineering and we're hoping these new features will give our customers
a leg up.

Sorry for the lengthy note - happy to take questions, slings, arrows, etc.

Ross Rader GM, Hover ross@hover.com

~~~
SkyMarshal
Fwiw, let me share some of the less predictable consequences of what could
happen if your pwd database is hacked, and why it's important to use bcrypt,
PBKDF2, or scrypt to secure your users passwords. (<http://codahale.com/how-
to-safely-store-a-password/>)

I was one of the folks whose email and password were compromised in the recent
MtGox.com bitcoin exchange attack. Until then I had been using a three-tier
password system, consisting of three passwords of increasing difficulty, used
for sites of increasing levels of importance.

My bank/card accounts, email accounts, and any account that stored bank/card
info (Paypal, Square) got the strongest password. Sites that were part of my
online identity or similarly important, but did not store financial data, got
the next strongest password (Twitter, Facebook). Finally, spam sites I didn't
care about but needed a login for some reason got the third password.

Well, the MtGox hackers got my middle-tier password and the associated email
address. Shortly afterward they also got my Twitter account, which used the
same for login. Fortunately they didn't take the time to change my email
address, and I was able to get it back with a password reset email.

And a few days later I tried to login to Amazon and found they had changed the
password there too. I got it back the same way, pwd reset, logged into AWS and
found my EC2 test instances had all been terminated and all the work I had
been doing there gone.

Now I'm sitting here wondering what's next, as I can't remember all the sites
I used that email/pwd combo on. But I'll never make that mistake again, and am
now evaluating password managers like Lastpass, Keepass, Passpack, and
Clipperz for storing unique, strong passwords for every site I use.

I'll also never use MtGox again, and have discovered a newfound wariness of
_all_ websites' security practices. One report like this is enough to make me
not only file away the name of the site, but also the people who built it, as
unreliable.

My point here is that, if your database gets pwned and distributed out to the
black market, there's a realistic chance your users will be harmed in ways you
haven't foreseen, on other sites not related to yours, and will remember and
blame you for it indefinitely.

Given that most people have lots of sites they log into, and that most can't
or won't remember separate passwords for them all, you can assume a good
portion of your users reuses passwords.

The potential downside of those reused pwd's getting hacked via your site and
put into the underground identity-theft rings and whatnot, far outweighs
whatever user-experience upside you may perceive.

~~~
ydm
I agree with you wholeheartedly. Unfortunately, there will always be a few
services that will store passwords in plain text.

Would unique email addresses for each service have helped your situation at
all?

For example:

Facebook email: uniqueemail1@gmail.com (forwards to your real email) Facebook
password: password1

Hover email: uniqueemail2@gmail.com (forwards to your real email) Hover
password: password1

Bank email: uniqueemail3@gmail.com (forwards to your real email) Bank
password: password1

If any of those services get hacked (and the passwords are stored in plain
text) then there's nothing connecting those accounts to each other since the
email addresses are all different.

It's the system I use (along with 3 tiers of passwords not just 'password1' as
used in the above example).

~~~
s3b
But then even if you remember the password, you'd still need to remember the
right unique email id for each service.

~~~
yuhong
Not to mention it is security by obscurity.

------
iamichi
I emailed a major technology retailer about this when they sent me my password
in plaintext. This is the response I got (I pointed out that she made my point
for me, but I didn't get another reply)...

Dear XXXXXX

Thank you for your email dated xx/xx/2011. I apologise for the delay in my
response.

The only way that people can get your password is to hack into our system or
your emails. It has to be sent in plain text for you to know what your
password is.

I hope this helps.

Kind Regards

Xxxxx KNOWHOW Customer Support Dixons.co.uk

------
eneveu
Seems like they listened: [http://help.hover.com/2011/07/07/hover-secures-
passwords-wit...](http://help.hover.com/2011/07/07/hover-secures-passwords-
with-bcrypt-and-enhances-usability-with-identity-verification-tools/)

Well done, hover!

------
dieselz
I take this approach to security: I do everything I can possibly think of to
secure an application. Any barrier that you setup now could save you 100x the
time (& pain) later. Saying that one part is secure enough is asking for
trouble.

------
damncabbage
<http://jumba.com.au> does this as well; when on the phone to you, they _ask
you for your password_ , and the customer support person _checks it on their
screen_.

(What could possibly go wrong?)

~~~
swaits
Are you sure of this? The CSR could also be comparing the
hashed/bcrypted/whatever version of the password you give them over the phone
to the hashed/bcrypted/whatever version stored in the database.

~~~
damncabbage
To activate SSH on your account, you are required to dump your password into
the free-text area on a support ticket (see
[http://support.jumba.com.au/kb/questions/45/Do+you+offer+SSH...](http://support.jumba.com.au/kb/questions/45/Do+you+offer+SSH+access%3F)
).

Given they do this sort of thing, even if they did do fancy hash comparisons
when I called them, they still have people's passwords hanging around in plain
text elsewhere on the system.

~~~
swaits
Wow, ok. Yah that sounds about as bad as it gets. Stay away!

------
krashidov
I guess these guys have taken a fondness to the Anti Security movement...

On a more serious note though its dangerous enough to store passwords in
plain-text, announcing it to the world is a bit stupid.

------
billmcneale
"Initially, we were emailing reset instructions but people complained that
they didn't receive the email. In order to fix this problem, we are now
emailing you your password".

Makes perfect sense.

------
bkorte
Damnit, transferring domains is such a pain in the ass.

------
pwaring
My hosting provider (Bytemark) sends out passwords in plaintext, though I'm
not sure if they're stored that way. It is a _lot_ more convenient that having
to follow a password reset link, though I'm not entirely convinced by the
security/usability trade-off (there's not much on my accounts, since the
password simply allows access to the control panel, not root access on the
machines).

~~~
pavpanchekha
If you can retrieve the plaintext, it doesn't matter how you store them. Keep
in mind, access to the control panel probably means they can CNAME your
address over to their own and start dispensing viruses and malware from a
look-alike site.

Storing passwords recoverably is more or less and unforgivable sin; thinking
that it is in any case a good idea is a mark of terrible naivete. Because
you're compromising the security of yourself, your users, and any other
accounts on any other services that your user uses.

~~~
pwaring
DNS is handled separately, so there's no chance of any of my domains being
'taken over'. The control panel doesn't actually allow you to do that much,
and changes to the billing contacts result in a confirmation email being sent.

As for password storage, it's possible that they are encrypted, with the
private key held on a separate server, so if you managed to get hold of the
user database you wouldn't necessarily be able to access the passwords.

------
Jach
Interesting use of emoticons in that section.

I think we've found a suitable candidate for a first-pass Internet Driver's
License test. Filling out a few forgot password forms, checking email,
checking spam in case it went there, clicking on a link, and changing to a new
password that's >= 10 characters and not a dictionary word...

------
brendoncrawford
This seems like a good time to mention that I highly recommend using the
Password Hasher extension if you are on FireFox. It does help to alleviate
problems like this:

[https://addons.mozilla.org/en-US/firefox/addon/password-
hash...](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)

------
benbeltran
From reading the post, I think the post says that they'll give users the
option to choose if they want their password to be encrypted (and any reset
request will contain a URL) or not to be encrypted (and they'll send the
plaintext).

This way they'll satisfy all users (or so they think.)

I hope they default to the secure method.

------
PonyGumbo
FYI - Hover is a front end for Tucows / OpenSRS, which also store passwords in
plain text.

~~~
freejack
Nope, this issue is uniquely ours and has nothing to do with OpenSRS. I
usually try not to speak for them, but I can say authoritatively that this
simply isn't the case.

~~~
PonyGumbo
OpenSRS emails both username and password to the administrative address on
file when a customer completes the "forgot your password" routine on reseller
storefronts.

------
mattsidesinger
"We acknowledge that ours is not the most secure approach." Sounds more
eloquent than, "We acknowledge that ours is the least secure approach."
Although, the 'smileys' were a nice touch and made me feel more secure.

------
rowanseymour
I've given up on trusting any site to protect my password, so now I use
passwordmaker.org to create my own hashed site-specific passwords.

------
Uchikoma
Is there a website that lists all services that store plain text passwords?
(so one can avoid them)

~~~
boot13
This is the closest thing I've found: <http://plaintextoffenders.com/>

------
shapeshed
SQL injection anyone? I hope the app is secure

------
bad_user
Btw, DreamHost does it too.

------
drivebyacct2
Oh jeez. I was enjoying the conversation about looking out for dumb users and
just giving dumb users what they want.

Hover is a domain registrar. I'd rather use GoDaddy than give someone business
that tells me that my passwords are stored in plaintext because customers want
it. I'd like to login everywhere with just my full name and phone number, are
they going to implement that?

------
bkaid
Next weeks headline: "Anonymous hacks Hover.com, user database of emails and
plain text passwords posted to torrent."

------
Kwpolska
"Hover.com: the 'change your password' and 'close account' buttons were
removed"

------
chrisjsmith
Arrogant idiots! Nothing more can be said.

------
edgardcastro
I knew bcrypt/scrypt was just a hype! ;)

------
dexen
Please correct me if I'm wrong, but... storing password hashes (actually key
derived from password) is only meant to secure up password re-use. If there is
any other reason, please disregard the text below and just correct me ;-)

Isn't password re-use a social problem rather than technical one? Perhaps we
ought to use a different -- social -- measure to prevent password reuse.
Throwing technical solutions onto social problems doesn't seem to work.

Proposal: let's store all passwords plaintext and force users not to re-use
passwords, ever. Let's have every password-using service and system make
available hashes (derived keys, to be exact, bcrypt() style) of the passwords
completely public; when a person tries to create a new account, the service
would check a good bunch other services against password hash matches. If the
new password (used upon registration) hashes to the same value as on any
checked service, the user is rejected and publicly shamed for endangering the
service and his account. More checks cound be performed after the registration
in background, to lessen the delay on registration.

That's it. Social problem, social solution.

~~~
kogir
You're wrong. I use hashes so that if somehow the hashes and salts leak the
attacker can't now log in as any user with no additional effort. While it's
true that a hash compromise typically means you're owned, not having plaintext
passwords available still makes further exploitation slightly harder. For
instance, read only SQL injection that leaks hashes won't let the attacker
write anything.

