Let’s talk about usernames

Re:Let’s talk about usernames by slavik81 on Monday February 12, 2018 @02:29AM (#16357121)

Given that we're developers and we make the tools that the help desk people use, why would we make a help-desk password reset that can send to a different address than the one registered with the account? Couldn't there be other social engineering tricks people could pull on your help desk employees that you haven't yet imagined? Maybe they also think it's ok to drop the underscore from my email address, despite that not being a part of the gmail scheme.

[ Parent | on HN ]

Re:Let’s talk about usernames by baystep on Monday February 12, 2018 @04:41AM (#16357593)

What about the "I've lost that email account, can I switch it to another to recover my account?" case. Or the "I'm the legal guardian of this person and need the account control switched to my personal email", or in the business world "this employee doesn't work here anymore and as administrator I would like the account transferred to me" cases. Locking customer support systems down tightly has it's own pros/cons.

[ Parent | on HN ]

Re:Let’s talk about usernames by slavik81 on Monday February 12, 2018 @07:28AM (#16358179)

I suppose I was more specific than I really should have been. More broadly, I'm trying to say that you have control over the tools and processes followed by your customer service. They can be used to combat social engineering.

For something as important as the credentials for a bitcoin exchange account, as Alex gave as his example, there should be policies specifying the reasons why account credentials can be changed and what evidence must be presented to do so. Front-line customer service reps shouldn't be flying by the seat of their pants when making difficult decisions with potentially hundreds of thousands of dollars on the line.

[ Parent | on HN ]

Re:Let’s talk about usernames by Alex3917 on Monday February 12, 2018 @09:10AM (#16358624)

What happens when someone calls the CS person and tells them to type in their email address instead of copy pasting it or whatever. If there are any bugs at all in the CS software then it won’t be hard for the CS person to believe there is a bug they need to work around similar to the other bugs that are already in their dashboard.

The point of social engineering attacks is that they’re innocuous requests that don’t raise suspicion, and are hard to train people against.

[ Parent | on HN ]

Re:Let’s talk about usernames by ubernostrum on Monday February 12, 2018 @02:35AM (#16357152)

OK. You go get every single company, site and service on earth to deploy a 100% perfect credential-recovery system and only have it used by 100% perfect people who never ever make a mistake. And when you've finished, let me know and I'll rethink my approach to email.

[ Parent | on HN ]

Re:Let’s talk about usernames by slavik81 on Monday February 12, 2018 @02:50AM (#16357191)

You don't need to make a system that's perfect. You just need to make a system in which checks are required to make _any_ change the credentials on an account. Once those checks are complete, it makes no difference if the change is from [email protected] to [email protected] or to [email protected].

[ Parent | on HN ]

Re:Let’s talk about usernames by Alex3917 on Monday February 12, 2018 @09:04AM (#16358579)

It’s not just password resets that are the issue. It’s also things like:

- Functions to get the account based on the email address

- Internal tools

- Stored procedures and other SQL stuff that happens outside the main code base

- Third-part integrations (Mailgun, Sailthru, ZenDesk, SalesForce, etc.)

That’s a huge attack surface where if there is even a minor mistake by a junior dev that no one noticed then everyone is going to lose their assets under protection.

[ Parent | on HN ]