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.
It's not just domain registrars, I reset the password of my basecamphq.com account (which stores very confidential project information) last week, and received this email:
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.
It blows my mind that even 37signals falls for this trap. There should be a website showing a blacklist of services that store passwords plaintext.
As I'm sure you noticed, many of those sites are putting the password in the welcome/verification email, but this is not the same as actually storing it as plaintext in their database. The thing to look out for is your old password in password reset emails, not welcome emails.
And another one to add to the list: my brother's small business uses British Telecom for email hosting. Their control panel stores the password in plaintext.
I'm surprised you haven't been prompted to upgrade your account. 37signals switched to a new login system 18 months ago which doesn't store passwords in the clear. With a new login you get a regular password reset email.
Because the newer login system requires you to move away from having any easy to remember username (eg. someperson) that only needs to be unique on a particular Basecamp instance, to picking a harder to remember new username (eg. someperson5946) that needs to be unique everywhere.
Companies like Hover have a user/password scenario unlike e.g. an email provider: users only visit their site one/two times a year (to renew a domain or whatever).
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.
I love this idea. 90% of the time when I use a forgot password link, I'm really trying to auth-by-email. I'm not sure how it would work for reusable links, since that becomes auth-by-URL, which seems significantly less secure— maybe putting HTTP auth in the url would be less likely to be logged at any point?
Auth emails are like plaintext passwords. Best combo would be your public key stored on their server. Any future requests, they send you the PGP'd email.
Not if the link can time-out or expire after X [days, minutes, seconds, ect]. When I think of emailing my self the password, I think of storing it in plain text in my email account. When I think of authentication via email I think of a one time use link that allows me to log into a session.
Email is sent in plaintext. It'd be easy enough for an attacker to request an email authentication (which it then sniffs in transit). Expiry time doesn't help much.
Email auth really should be done as Joakal says - your public key stored on their server when you sign up, email auth is encrypted. Trouble is, it's "too hard" for "normal people". If gmail/outlook etc supported it, though, it could catch on.
We're starting out from the position that my email is the keys to my digital castle... good or bad as that may be, if someone can reliably sniff my email in transit they already own my life.
It is oauth for all intents and purposes— a third party (your email server) authenticates you as the owner of the email address and passes you a secure token.
It's worse in some ways (control, usability, security) and better in others (simpler technologically, everyone has it).
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".
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
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?).
Gandi is super awesome ! One quick thing though: since last year they have a US subsidiary (see http://en.wikipedia.org/wiki/Gandi), which might or might not make them more susceptible to US law.
Gandi is great and resilient. I know from personal communication with them that the Yes Men recommend using their domain services (they also favor joker.com, which is based in Germany -- I've had a good experience there as well, although Joker doesn't offer VPS services like Gandi).
I've had other positive experiences with Gandi.net: They hooked one of their VPS servers up with a BGP feed so I could announce my AS there for testing a new Anycast service.
Name.com is great. They don't try to obfuscate the UI to make it more user friendly. Straight access to the DNS records, simple clean design. Here's an old link to a comment I had discussing them: http://news.ycombinator.com/item?id=1766590
Switched to Name.com around that time too. The website stripped special characters from my password during registration and I couldn't understand why it wouldn't let me log in since the limitation wasn't mentioned anywhere. Had to confirm with customer support. Take that as you will.
But I like how they send you an email on every failed auth attempt.
I absolutely love NearlyFreeSpeech.net for domain registration (and also cheap hosting).
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.
Precisely. Doing something like this is always a trade-off, and yes, it might make sense for something like a blogging service (the same way Posterous inbound mail has the small potential to go wrong), so I can see where Hover is coming from. But really, in the case of a domain registrar, wow. If you're administering a domain, you're no longer in "mainstream user" territory.
There should really be some minimal set of conditions for domain registrars, with one of them specifying a reasonable security model for password retrieval.
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.
I dropped DreamHost after a week when I called up about an issue and the customer service person wanted me to verify my identity by telling him my password.
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."
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.
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.
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?
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?"
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.
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.
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.
I see were going to argue about whether to ascribe to malice, that which can be explained by stupidity. I'm going to go against the aphorism and say "malice." I suspect they know exactly what they're doing, and they also know that their strategy of "security be damned, let's sell some more domain names" requires a plausible explanation of security, thus they come out and tell us something that you and I know to be false.
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.
I think it's slightly more likely that they think it might be true, and they want it to be true, so they're going to be incurious. Either way, my only real point is: there's probably going to be SQLI somewhere in that app too. And if they take file uploads anywhere, my guess is you'll be able to run code remotely.
(I know neither of these things to be true for a fact and am just making a rhetorical point.)
The URLs are usually time-linked, one-time, and service-specific, as opposed to the password, which 1) is permanent, 2) can be used without the user knowing, and 3) is likely to be used on other services as well.
You appear to not understand how password hashing works. A well designed hashing function is one-way, it cannot practically be reversed. With a large salt, even very weak passwords ("cat") cannot be reversed.
Not only that, but the size of the "salt" has nothing to do with how long it takes to brute force a password. We should stop saying "salt" and start saying "randomizer" so at least people understand what that thing is doing; I think everyone understands intuitively that a hash can be "randomized enough" so that further randomization isn't a win.
The problem here is that this is what customers want
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.
You know this and I know this, but the way the marketplace works is that if nobody intervenes, people buy food that kills them, cribs that kill their babies, pajamas that catch on fire and stick burning plastic to their skin, and so forth.
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.
I disagree. All they did (edit: to clarify, it seems to me that they only tried two alternatives) was try sending a password reset link and the unencrypted password itself. I don't think sending the user a new password would be that big a deal (we're assuming they receive the email, as both methods will fail if not), and you could show them the password reset page immediately after they logged in with the new password.
If the password reset function sends a temporary password just as you say, THEN it is not that big a deal. On the other hand, if they are storing every user's original password in such a way that they send the user their existing password...
I believe this is the scenario most people here think is happening.
Even if you accept that this isn't wrong because it's what customers want; if it's broadly unknown (by this community) it becomes newsworthy because HN would probably not want to think of itself as at the bottom of the barrel, and will be more than willing to move away from a host that shows such a flagrant disregard for security.
It isn't wrong in exactly the same way that selling cigarettes isn't wrong. I'm not saying it isn't noteworthy, just that like the tobacco problem, we shouldn't fall victim to thinking that Hover.com's choices are the only problem.
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.
I find it very interesting that a domain registrar has a customer base demanding this. In my anecdotal experience domain registrar customers do vary a bit in their technical knowledge, but overall are above average.
As for being what the customers want, not this customer. I'll definitely never become their customer if they are this insecure.
>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.
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.".
> 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?
"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?
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.
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.
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.
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.
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.
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)
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.
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.
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.
They still do this??? I was a previous MT customer and I was blown away that they asked me what my password was over the phone. Shortly after, they upgraded their support system with temporary PINs and I've never been asked again.
"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."
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.
Not necessarily, if they hack into one system then getting into another isn't automatic. If the passwords are in a separate filesystem/database than the key, and linked only with software, then unless it's the software that's comprised it would still increase the difficulty of getting both the password and key significantly. It also prevents trivial browsing of passwords via sql commands by rouge employees.
With symmetric encryption, probably (assuming the data wasn't gleaned with a purely SQL injection attack). With public key/private key encryption you could probably do it more securely by not letting the private key anywhere near the main app/web servers.
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.
Generally it's pretty easy to get root on a system. Then you're generally 100% owned. The only away this will survive is on the good graces of malicious hackers everywhere.
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.
They are sacrificing the security of their customers for business reasons (usability will increase retention).
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.
Their rationale doesn't make sense to me. If they wanted the same recovery process, they could just send you a new, generated password in a recovery email instead of keeping your actual password in plaintext.
No, but it's pretty damn important. All it takes is one disgruntled employee, one uninformed sys-admin, one mistake, and boom, all that "security" is gone.
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.
Broadcasting this fact is almost as bad of an idea as implementing it in the first place. You now have a bullseye on your site from every blackhat reading this. It's your company and your customers (which I am not one of), so most of the time I would just say do whatever you want, because it doesn't affect me. Problem is, it does. It affects every developer out there, because once your security is compromised and every password is leaked by LulzSec, Anonymous, ScriptKiddies, etc... we're all at risk.
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'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.
"why would your team not opt for things that ARE vetted as being secure, trusted, open, and have widespread adoption?"
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.
I'd hope in the future, when your engineers throw a fit, you take some time to learn why you're wrong up front rather than overruling them. This was a huge mistake on your part and it's now public; you have a limited amount of time to fix it before you're hacked.
There was a bit more to it than that, but on this specific point, lesson well learned. I rushed this instead of looking for an agreement - as they say, measure twice, cut once.
What's to stop me (possible hover CSR, co-worker, whatever) from simply reading a high-profile customer's password and transferring all their million dollar domain names to me later that night when I get home from work?
I have a pretty good memory. I bet I could remember 5-10 simple passwords and email addresses without writing anything down. Chances are the idiots use the same password for their email anyways.
Muahahaha, I'm rich, and your company is going down the tubes in a lawsuit. See you later!
Industry secret - at the most basic level, registrar and registry staffers don't need access to a customer account to manipulate a domain name. We've implemented tons of controls to manage who can do what, etc. but relying on customer passwords to safeguard domain names from internal tampering isn't really a great tactic.
What about the same scenario, but instead of altering domain records, a CSR logs into the customer's e-mail account, or bank account, and starts wreaking havoc?
What? If it's the same scenario then the CSR does not and never did have the password, they just have domain control panels. The whole point is that they can't do that.
Is it not? Passwords are in plain text in a database; I didn't see any comments where he said CSR's don't have access to them, he merely said that CSR's don't need access to them to muck around with their stuff.
"...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 personally don't see how having the plain-text passwords help in the case where the person owning the account doesn't have access to their email account. Since they don't have access, you can't exactly email them their password.
Assuming you verify users over the phone securely, why not just reset their passwords for them with a one-time use, temporary password? Surely that's not much harder for the end-user to deal with, and then you needn't store their password...
Thanks for taking the time to respond. At a minimum, it's good to know that you're a HN reader.
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.
Thanks for the note. We're lining up to knock this out quickly. Drop me a note to ross@hover.com if you like and i can fire you an update when we update password security and the rest of the related tools. We can set you up with a corporate level account of course, just let me know if/when you are ready.
With 100 domains you may want to try contacting Fabulous.com. They live up to their name. You're a bit low on the required names but worth a shot. If you get in, you'll be saving a lot more money and the service is the best in the business.
Thanks. I took a look at Fabulous.com. I recall checking them out once before based on a HN recommendation. They're out of my league. When I say I have 100+ domains, I mean like around 105 (give or take). I'm not really a 'domain professional.'
For the reference:
> To be eligible for a Fabulous account we
> require that you meet at least one of the
> following:
> Domain portfolio must generate US$750+ per month
> Transfer 750+ domains to Fabulous
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.
I had been using a three-tier password system, consisting of three passwords of increasing difficulty, used for sites of increasing levels of importance.
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.
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).
>Now I'm sitting here wondering what's next, as I can't remember all the sites I used that email/pwd combo on.
LastPass lets you import your passwords from your browser.
I also had my details leaks via the MtGox.com hack. Fortunately I have been using a password manager for years (Keepass) and don't share passwords site-to-site. So I don't fuck around with security, or try not to.
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.
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.
I don't disagree with most of what you are saying, and would add that good security practice is a shared responsibility. Sharing passwords across sites is the user equivalent of storing passwords in plain text. i.e. It might be secure enough until its not.
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 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.
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.
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.
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.
"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".
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).
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.
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.
AFAIK using simple reversable encryption may prevent a simple SQL injection attack, but of course it won't help if the attacker can gain root on the server, which is much harder though.
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...
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:
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.)
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.
OpenSRS emails both username and password to the administrative address on file when a customer completes the "forgot your password" routine on reseller storefronts.
"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.
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?
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.
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.
Social problems can get technical solutions. That distinction in bullshit and should be educated out of the Hacker populace. Password reuse (which, BTW, is not why we hash passwords) can be solved otherwise; for example, you can hash passwords client-side and then again server-side, both times salting with a unique salt. That way, the password itself is uniquified in a non-reversible way by your salt (which is presumably not used elsewhere). Your client-side hash can be very expensive, since it's done on the client, and the password you recieve (the hash, that is), is guaranteed unique.
For most people the social solution creates a worse usability problem than the one Hover is trying to fix. With unique passwords, the user is now responsible for maintaining (and securing) a list of passwords. Password managers can help here, but this assumes that the password manager doesn't have exploitable vulnerabilities of its own. In addition the password manager may not be accessible when not using the "home" computer.
If someone gets read-access to this database he can log into my account independently of me reusing passwords (which I don't) or not. The problem is not on my side.
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.