6 ms·

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 c

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

jat850 15y ago
Quoting you here: "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
- freejack 15y ago
  "why would your team not opt for things that ARE vetted as being secure, trusted, open, and have widespread adoption?" It was a classic case of letting product management opinion over-ride engineering implications. Namely, on behalf of customer service, I went to bat - hard - with the engineers, to give our CSRs a completely effective way to handle inbound password requests in cases where customers no longer had access to their email account. I can't remember the exact conversation, but I could see the engineers at the time characterizing it as "being over-ruled". Long story short, brought forward almost two-years - we've got a new team on the project and I have a much greater appreciation of the subtleties and trade-offs and we've still got some work to do to fix my mistakes. /r

jat850 15y ago

Quoting you here: "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

freejack 15y ago
"why would your team not opt for things that ARE vetted as being secure, trusted, open, and have widespread adoption?" It was a classic case of letting product management opinion over-ride engineering implications. Namely, on behalf of customer service, I went to bat - hard - with the engineers, to give our CSRs a completely effective way to handle inbound password requests in cases where customers no longer had access to their email account. I can't remember the exact conversation, but I could see the engineers at the time characterizing it as "being over-ruled". Long story short, brought forward almost two-years - we've got a new team on the project and I have a much greater appreciation of the subtleties and trade-offs and we've still got some work to do to fix my mistakes. /r