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.
Hi -name-,
Can't remember your password? Don't worry about it — it happens. We can help.
Username: -username-
Password: -password in plain text-
Please keep your password safe to prevent unauthorized access.
So I wonder if they should instead allow "authentication-by-email". Basically, make it work just like current reset emails (with an embedded randomized link that allows access), but prevent the link from expiring.
Obviously that suggestion has a lot of holes in it, too, but it's something to consider, especially since it's not a new idea.
Either way, it's a real amateur move to do away with hashing.
What registrar would anyone say is the most security focused and/or government resistant?
Maybe it should be a 2011 AskHN?
Can't recommend Gandi enough, they do exactly what they say on the tin - "no bullshit".
I wouldn't say they're security focused, but they allow you to be totally anonymous in your registration, and have a policy of hosting anything that isn't illegal.
There should really be some minimal set of conditions for domain registrars, with one of them specifying a reasonable security model for password retrieval.
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.
I explained that I didn't trust him to know my password (assuming he was just typing it into a box), and he said "well its right here in front of me, im just making sure it matches."
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.
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.
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.
The Big Problem here isn't that Hover has decided that user convenience warrants storing passwords insecurely. That is a problem, of course, but it is not as big a problem as The Big Problem here.
The Big Problem is the grafs spent defending the soundness of Hover's password storage strategy. Hover does not appear to understand that they have conceded user security. They believe that a combination of their network security and physical security† mitigates these flaws. If you're going to sell out user security to minimize customer support costs, I'd at least like to know that you know that's what you're doing.
That Hover does not appear to know what they are doing suggests that there is much more badness to be had in their systems, which is a problem that will burn them much more painfully than password hashes.
† Notably, not application security --- no external auditor would let "user passwords appear in plaintext in a database column" slide.
But the audience for this blatant nonsense are the people who want Hover.com to mail their password to them, so they think they can get away with telling us that "a combination of their network security and physical security† mitigates these flaws." You know this to be false, I know it to be false, and I suggest they know it as well.
That is not how I read it. You could argue the other way:
If they have to send password reset URL:s anyway, they can just as well send the password itself.
That makes sense. It's just that by storing the passwords at all, you risk losing them if someone gains access to your database.
And I want a pony, they gonna give me that too?
A business transaction is a negotiation between seller and client. You don't always have to give them what they want, and if you are good enough, people won't leave you over that one thing.
If you are going to only use sites that store your password in plaintext because it is so damn convenient, you are not going to have much Internet left.
So we draw a line somewhere and say that those products and services over there, caveat emptor. These over here, OTOH, must have a minimum standard of safety.
I am personally not convinced that domain registration should be left up to the marketplace. What if someone gets a user's password and then redirects their web addresses to a site that dispenses malware?
The victims in this case aren't even the domain registrar's customers, they're people who had absolutely no say in the question.
But any ways, I wasn't really trying to suggest we regulate it so much as suggest that laughing at Hover.com is looking in the wrong direction. There is a large social problem isomorphic to the "disable your security software if you want to see a video of dancing babies" problem. That problem is far more interesting and important than the "greedy businesspeople are greedy" problem.
Win/win.
I believe this is the scenario most people here think is happening.
First off, nobody chooses their domain registrar because it provides plain text lost passwords instead of something more secure. That is such a silly claim that I would hope you don't actually believe it. However, people will certainly leave a domain registrar based on an insecure password policy. This is especially true of the people who frequent domain registrar services.
Second, you claim the market is failing. It's doing exactly the opposite. You are commenting on a widely read post with hundreds of comments and many thousands of views that is in the process of putting a black mark on this stupid company as we speak. They will get a nontrivial number of emails and cancellations referring to this post, and I guarantee they change their policy within the month. This is exactly how the market is supposed to work.
As for being what the customers want, not this customer. I'll definitely never become their customer if they are this insecure.
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.
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?
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?
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.
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.
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.
> 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.
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.
*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.
Of course, the more separation you have between the public and private keys, the less convenient it is to actually do anything useful with the plaintext.
Number one, I'd love a citation on that in general. Root privilege escalation vulnerabilities in the Linux kernel are fairly rare.
Number two, how does an SQL injection turn into any sort of shell access magically? Not without some other obvious security shortcomings.
If they get hacked, if/when they send out a disclosure they'll just say that personal information may have been leaked.
Sure, they've made their case for it, but it's only slightly less disconcerting than if they didn't know what a hash is.
Actually, it's probably worse, because at least someone that doesn't know about hashing could be educated - these guys have shown that they put profit above protecting their customers.
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
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.
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).
Now I'm sitting here wondering what's next, as I can't remember all the sites I used that email/pwd combo on
For my banking password I have a base password that I always add something to for each site in a way that I can remember without having to write something down. The idea being that although it might be obvious to any human looking at the password what I've done it's far more likely that attackers will be automating checking passwords on different sites and the program will just see my password failing on all other sites and ignore it.
But, you do. It's hindsight, sure, but if you read HN you definitely know better, yet you did it anyway. You've learned your lesson, and hopefully the next time a service you frequent is hacked your exposure will be minimal. But it took something like this for that to happen. I'm thinking a lot of sites have had shitty security for years like Hover et al and are only now, with all the publicity surrounding recent breaches of security, beginning to realize they can't get away with it for much longer.
So just like anyone can cut you some slack, I can cut organizations some slack, for now, especially in cases like this where it looks like someone without the requisite technical expertise was given too much control over technical decisions (i.e. not the engineers' fault). That kind of shit happens all the time even if it ideally shouldn't. But, things have changed and security concerns have gained enough publicity that even clueless middle managers should have some inkling that it's important, so IMVHO if you haven't gotten your shit together security-wise as an organization by the end of this year, you're probably inept enough that I shouldn't be doing business with you.
In the meantime I'll practice the security diligence I preach.
"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."
Your point isn't invalid, but can be addressed in some way by a combination of a good customer support team, and two-factor or multi-factor authentication.
I think your transparency and accountability is great, but one thing I would say is this: This is a well-traveled discussion, no new ground is being addressed here. Your company has willingly made a tradeoff of security vs. usability. It's not one that I would make or accept (as a developer or a customer). But whatever solution your team may have chosen should be contrasted against (and I apologize for not having a real quote handy): Don't fool yourselves into thinking you can do security "better" than someone else.
As clever and intelligent as your team may be, time after time, weird encryption or password hashing or things that are homegrown implementations of these principles have shown to fail again and again and again.
So, knowing that, why would your team not opt for things that ARE vetted as being secure, trusted, open, and have widespread adoption?
Bridge the gap of customer frustration (and your other queries about domains disappearing, emails being lost) through good customer support. Otherwise it feels like you're ultimately only playing a game against time and inevitable loss/breach.
edited a few weird grammar issues
It was a classic case of letting product management opinion over-ride engineering implications. Namely, on behalf of customer service, I went to bat - hard - with the engineers, to give our CSRs a completely effective way to handle inbound password requests in cases where customers no longer had access to their email account. I can't remember the exact conversation, but I could see the engineers at the time characterizing it as "being over-ruled". Long story short, brought forward almost two-years - we've got a new team on the project and I have a much greater appreciation of the subtleties and trade-offs and we've still got some work to do to fix my mistakes.
/r
I understand you did this for your users and your product, but please reconsider. Your users are also everyone elses users, so your lack of proper security is shared amongst all of us.
I've got 100+ business domains at GoDaddy. I've had a todo to move these somewhere for a while now and Hover is (was?) my top target. Coincidently, about a week ago I opened a Hover account and registered my first domain there.
Hover got my attention because you seemed to be the anti-GoDaddy. Now I may re-evaluate my options. Hopefully security may get a re-look from you guys by the time I get to that pesky todo on my list.
BTW: I'd love some kind of corporate level account for customers with my level of domains. I'm small potatoes for some of the other corporate domain registrars. Thanks.
1) I simply don't believe your claim that the number of stolen emails is so high that sending password retrieval links via email is unfeasible. This isn't a new problem that is just faced by hover.com, and most solve it without resorting to plain text passwords.
2) You aren't taking a wide enough view here. By storing and sending plaintext passwords you are doing more than making someone's hover.com account insecure. You are creating a weak link that may reveal a user's password that is used in any number of places. If I were to use hover.com, and someone got access to your DB, they would get my 2nd tier PW and instantly have access to my Facebook account and a number of other things that could cause havoc in my life. This seems obvious, but there is little to no acknowledgement of this fact in the post above.
3) Trust has been lost, as account security is clearly not a priority among your engineers. You may change things, but those changes will be made by someone who thought storing plain text passwords and sending those passwords in email is OK. Even after passwords are no longer sent around via email, who knows what kinds of other security flaws will remain that aren't clearly explained on the corporate blog?
With all this being said, it's great that you came here to acknowledge fault. Best of luck to you, but I have to say that I won't ever be a customer.
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
Well done, hover!
(What could possibly go wrong?)
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.
On a more serious note though its dangerous enough to store passwords in plain-text, announcing it to the world is a bit stupid.
Makes perfect sense.
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.
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.
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...
https://addons.mozilla.org/en-US/firefox/addon/password-hash...
This way they'll satisfy all users (or so they think.)
I hope they default to the secure method.
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?
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.