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.
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.
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.
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.
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.
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?"
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.
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 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?).
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.
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).
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.
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.
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.
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?
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.
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.
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).
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.
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.
"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."
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.
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.
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:
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.
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.
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.
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.)
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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?
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.
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.
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.
189 comments
[ 371 ms ] story [ 3663 ms ] threadIf 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.
*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.
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.
Is it worry that they are lax in security elsewhere?
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.
There should really be some minimal set of conditions for domain registrars, with one of them specifying a reasonable security model for password retrieval.
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.
But I like how they send you an email on every failed auth attempt.
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.
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.
It's worse in some ways (control, usability, security) and better in others (simpler technologically, everyone has it).
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.
What's the use of encrypting your passwords when you're broadcasting them to every mail server between your and your customer?
> 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.
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.
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.
https://addons.mozilla.org/en-US/firefox/addon/password-hash...
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.
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.
http://i-want-a-pony.com/
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.
(I know neither of these things to be true for a fact and am just making a rhetorical point.)
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.
https://secure.wikimedia.org/wikipedia/en/wiki/Password_hash...
And you'll still be able to brute force "cat" in under a day.
Win/win.
I believe this is the scenario most people here think is happening.
As for being what the customers want, not this customer. I'll definitely never become their customer if they are this insecure.
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.
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.
On a more serious note though its dangerous enough to store passwords in plain-text, announcing it to the world is a bit stupid.
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.
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.
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?
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.
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.