[jat850]

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]

"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

[gnaritas]

I'd hope in the future, when your engineers throw a fit, you take some time to learn why you're wrong up front rather than overruling them. This was a huge mistake on your part and it's now public; you have a limited amount of time to fix it before you're hacked.

[freejack]

There was a bit more to it than that, but on this specific point, lesson well learned. I rushed this instead of looking for an agreement - as they say, measure twice, cut once.

[GigabyteCoin]

What's to stop me (possible hover CSR, co-worker, whatever) from simply reading a high-profile customer's password and transferring all their million dollar domain names to me later that night when I get home from work?

I have a pretty good memory. I bet I could remember 5-10 simple passwords and email addresses without writing anything down. Chances are the idiots use the same password for their email anyways.

Muahahaha, I'm rich, and your company is going down the tubes in a lawsuit. See you later!

[freejack]

Industry secret - at the most basic level, registrar and registry staffers don't need access to a customer account to manipulate a domain name. We've implemented tons of controls to manage who can do what, etc. but relying on customer passwords to safeguard domain names from internal tampering isn't really a great tactic.

[pavel_lishin]

What about the same scenario, but instead of altering domain records, a CSR logs into the customer's e-mail account, or bank account, and starts wreaking havoc?

[Dylan16807]

What? If it's the same scenario then the CSR does not and never did have the password, they just have domain control panels. The whole point is that they can't do that.

[pavel_lishin]

I mean the scenario posed by Gigabytecoin, in which a CSR can read my password in plain text.

[keeperofdakeys]

"...to give our CSRs a completely effective way to handle inbound password requests in cases where customers no longer had access to their email account."

I personally don't see how having the plain-text passwords help in the case where the person owning the account doesn't have access to their email account. Since they don't have access, you can't exactly email them their password.

[freejack]

Most of our customer inquiries come in over the phone.

[JonoW]

Assuming you verify users over the phone securely, why not just reset their passwords for them with a one-time use, temporary password? Surely that's not much harder for the end-user to deal with, and then you needn't store their password...

[bluedanieru]

Hover customer here. Please don't do this again.

[freejack]

Absolutely.