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.
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.
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.
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.
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.
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.
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.
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.".
"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)
"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.
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.
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.
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'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.
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 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.
[+] [-] markbao|14 years ago|reply
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.
[+] [-] NiekvdMaas|14 years ago|reply
[+] [-] mmatants|14 years ago|reply
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.
[+] [-] mishmash|14 years ago|reply
What registrar would anyone say is the most security focused and/or government resistant?
Maybe it should be a 2011 AskHN?
[+] [-] mmahemoff|14 years ago|reply
There should really be some minimal set of conditions for domain registrars, with one of them specifying a reasonable security model for password retrieval.
[+] [-] geuis|14 years ago|reply
You absolutely cannot store passwords in plain text. There is no level of security you can wrap around the database that will ever be 100%. It only takes one mistake for everything to get exposed.
To try and reason that there is a trade off between customer support and security is ludicrous. Your reset emails aren't getting through? Work on fixing that damn system instead of exposing your customers to a world of hurt down the road.
[+] [-] xorglorb|14 years ago|reply
[+] [-] scottkrager|14 years ago|reply
[+] [-] raganwald|14 years ago|reply
So.
You either live with it and do your business with someone who has decided to offer a "premium" service and has a business model catering to educated customers,
Or:
You look for the government to regulate the marketplace as a public good. We do this with things like the safety of cars, we've decided that the marketplace cannot be left to decide this for itself. We attempt to do this with things like the content and handling of food, we've decided that the marketplace cannot be left to decide this for itself.
Perhaps the security of your account is not important enough to impose regulation. Perhaps it is. But as long as it's left up to the marketplace, the existence of companies like Hover is inevitable, and waggling our fingers at them is not going to do anything except make us feel smarter than the average bear.
[+] [-] mquander|14 years ago|reply
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.
[+] [-] tptacek|14 years ago|reply
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.
[+] [-] frossie|14 years ago|reply
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.
[+] [-] StavrosK|14 years ago|reply
Win/win.
[+] [-] estel|14 years ago|reply
[+] [-] balloot|14 years ago|reply
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.
[+] [-] city41|14 years ago|reply
As for being what the customers want, not this customer. I'll definitely never become their customer if they are this insecure.
[+] [-] eam|14 years ago|reply
Wait a second, so customers wont receive an email with a password reset link, yet they'll receive an email with a plain text password? I guess it's possible, but interesting.
[+] [-] kgermino|14 years ago|reply
[+] [-] arihant|14 years ago|reply
What I read - Because we aren't smart enough to create an automated password recovery that works, you should now trust that we are smart enough in network security to safeguard your passwords.
Also, these guys mention that they were receiving multiple requests. But how many requests came per user? If you got a million users and they each forget their passwords once a year and have to spend 5-10 minutes resetting it, I don't think its a usability problem at all, even if I get 1 million mails a year complaining about it. Its a bad decision for company handling domains and credit cards. And even if these guys really are good enough to secure their end of systems, whats the guarantee that my inbox is not compromised?
[+] [-] pavel_lishin|14 years ago|reply
[+] [-] naner|14 years ago|reply
If company X hashes your password on their server you still don't know that they did it properly or how good the rest of their security is. Basically the only way this differs is that you when you forget your password, your actual password sent in plaintext over the network and is now sitting in your email account. That makes me uncomfortable so I change it right away. Which is the exact same set of steps you would use for a hashed password reset.
Everybody focuses on the hashing thing like it is some kind of impenetrable defense or crystal ball into a company's security practices. It is not.
[+] [-] pavpanchekha|14 years ago|reply
[+] [-] pittsburgh|14 years ago|reply
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.
[+] [-] wccrawford|14 years ago|reply
Or maybe they wanted to test their security, so they're putting out an all-call to every blackhat out there.
Because either of those makes a lot more sense than what they've said.
[+] [-] alexmuller|14 years ago|reply
> I received this email when I registered with you last year, and was prompted by the recent creation of the site 'Plain Text Offenders' to send it to them. Somebody else has submitted their registration email too:
The reply was as follows:
> We realized that this area was of great concern to many customers and we have since removed password submission in our 'Welcome' email.
So to give their customers peace of mind, they made it less obvious that what they're doing is stupid.
[+] [-] joshontheweb|14 years ago|reply
[+] [-] rkudeshi|14 years ago|reply
[+] [-] macmac|14 years ago|reply
[+] [-] JohnsonB|14 years ago|reply
*edit: I just want to be clear, I don't actually think encryption would a sufficient replacement for a good hashing function, the question was just pointing out how bad this decision by Hover was; not only do they decide to make the password recoverable, but they don't even take whatever meager opportunities there are to make it at least somewhat secure.
[+] [-] ori_b|14 years ago|reply
[+] [-] zyphlar|14 years ago|reply
[+] [-] reitzensteinm|14 years ago|reply
[+] [-] scottkrager|14 years ago|reply
[+] [-] freejack|14 years ago|reply
I thought it might help to provide some further deets on that blog post.
I don't think we're making a case there, or providing an excuse - it certainly wasn't my intent to try and convince anyone of anything when I wrote that, but rather, it was an exercise to explain where we were (with that and other development projects) and where we were going.
We've gone back and forth on how we handle passwords over the years - and it has always come down to what type of interaction do we think will be best for our customers. I haven't re-read that post from April today, but I think I mentioned our last go-round on this made it much easier for our customers and customer service people to help in bound callers and sacrificed too much in terms of security.
We'll probably continue to go back and forth iterating the implementation, each time narrowing the swing of the pendulum until we find something that more appropriately balances what we think our customers are looking for in terms of security and usability.
I'd also like to point out that the scope of the risk isn't trivial. For example, URL-based password resets are only as secure as the mailbox they are sent to. i.e. a significant number of domains are stolen and threatened to be stolen through email account exploits (re-registering previously used addresses, forwarding attacks, etc.) This is made even more complex when a domain expires and email on that domain stops functioning. Where should the password reset go? We get dozens and dozens of calls a day from people in this position that need our assistance, making it tough to simply send out a reset request.
Anyways, I didn't come here to make excuses, I just thought I should acknowledge that we're aware of the gap (we caused it!) and working on it and considering the whole set of variables. Security is our primary consideration but that doesn't give us the luxury of ignoring the usability implications. Were that the case, we'd simply issue two-factor fobs to our clients and be done with it.
And finally, to those of you that guess at some sort of evil corporate motive or the involvement of stupid engineers, or even just dangling the implication that we've "Made a Final Decision" to store passwords this way, etc. It just isn't the case - our engineers are great and our motives are pure. If you want to blame anyone specifically, you can blame me for pushing the implementation in the direction I did. We're really just trying to do the right thing for our clients, and in this case, I took a great idea too far. Its just code, it can be changed - it will be changed, and changed in a way that will help our customer service staff continue to provide awesome customer service and also enhance the protection of our customers assets without stepping on toes in either regard.
We originally posted that commentary back in April because we had a ton of work backed up behind the release of our new domain and email management tools - which included a huge refactoring of most of the core code, transitioning to TDD and a ton of other important pieces. We were supposed to be done work on those pieces months ago, but as the management tools took shape, the task grew longer, pushing out these items to the point where it was getting embarrassing with our customers. That work shipped late last month and launches formally tomorrow putting us back in a place where we can get serious about the backlog. The new approach is pretty straightforward and moves us to a hashed password file, URL-based resets, etc. but also some identity verification features that our customers and customer support staff can use to validate who they are talking to in order to force resets manually. Its the validation piece that I'm most excited about given the extent to which the bad guys will go to phish a user out of their creds. We've seen some pretty sophisticated social engineering and we're hoping these new features will give our customers a leg up.
Sorry for the lengthy note - happy to take questions, slings, arrows, etc.
Ross Rader GM, Hover [email protected]
[+] [-] SkyMarshal|14 years ago|reply
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.
[+] [-] jat850|14 years ago|reply
"I'd also like to point out that the scope of the risk isn't trivial. For example, URL-based password resets are only as secure as the mailbox they are sent to. i.e. a significant number of domains are stolen and threatened to be stolen through email account exploits (re-registering previously used addresses, forwarding attacks, etc.) This is made even more complex when a domain expires and email on that domain stops functioning. Where should the password reset go? We get dozens and dozens of calls a day from people in this position that need our assistance, making it tough to simply send out a reset request."
Your point isn't invalid, but can be addressed in some way by a combination of a good customer support team, and two-factor or multi-factor authentication.
I think your transparency and accountability is great, but one thing I would say is this: This is a well-traveled discussion, no new ground is being addressed here. Your company has willingly made a tradeoff of security vs. usability. It's not one that I would make or accept (as a developer or a customer). But whatever solution your team may have chosen should be contrasted against (and I apologize for not having a real quote handy): Don't fool yourselves into thinking you can do security "better" than someone else.
As clever and intelligent as your team may be, time after time, weird encryption or password hashing or things that are homegrown implementations of these principles have shown to fail again and again and again.
So, knowing that, why would your team not opt for things that ARE vetted as being secure, trusted, open, and have widespread adoption?
Bridge the gap of customer frustration (and your other queries about domains disappearing, emails being lost) through good customer support. Otherwise it feels like you're ultimately only playing a game against time and inevitable loss/breach.
edited a few weird grammar issues
[+] [-] drgath|14 years ago|reply
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.
[+] [-] iamichi|14 years ago|reply
Dear XXXXXX
Thank you for your email dated xx/xx/2011. I apologise for the delay in my response.
The only way that people can get your password is to hack into our system or your emails. It has to be sent in plain text for you to know what your password is.
I hope this helps.
Kind Regards
Xxxxx KNOWHOW Customer Support Dixons.co.uk
[+] [-] eneveu|14 years ago|reply
Well done, hover!
[+] [-] dieselz|14 years ago|reply
[+] [-] damncabbage|14 years ago|reply
(What could possibly go wrong?)
[+] [-] swaits|14 years ago|reply
[+] [-] LawnGnome|14 years ago|reply
[+] [-] krashidov|14 years ago|reply
On a more serious note though its dangerous enough to store passwords in plain-text, announcing it to the world is a bit stupid.