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

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

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

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

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

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

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

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

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

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

Ross Rader
GM, Hover
ross@hover.com