Hello everybody,
Today at work, I've been facing an issue :
Client want a way to reset user's password for a web application. Classic.
For context, their is already a mechanism for every users to reset their password by receiving an unique link by mail.
However, he wants a way to choose the user's password when they ask to reset their password on support center (over phone)
Client argue that some of its clients, not tech people, have trouble using this mechanism or that email is not a reliable way to reset password (delay, possible loss of email when sending it, user unable to access their mailbox...). He also add that its clients have money and when something is wrong and they can't access their account, he want to provide them a way to allow an immediate login.
From my perspective, this involve some downsides :
- The probability that the user will change its password after getting one is close to 0. Or, as client said, if they are not tech people, they will always call support center asking for another password reset.
- This will overload support center and will make them less available for real requests.
- User password is no longer known by the user himself/herself. At least both admin/support center and user know it now. I'm attached to user's privacy, so this is a big one for me. I would not like to use a system where an admin can change my password as he'd like (of course, an admin can always change a password if he access database, run a custom script on server or whatever but this should not be a feature)
- If for any reason, a bug allow to run this unauthenticated, all users' account are compromised. This could not be possible if this feature was not asking to be implemented.
One alternative could be to generate a link for a one-time login and give them to the client, so they can log in and change their password (exactly the pattern of initial password reset, except we don't send it by mail) but as I said, support center is made over the phone, and asking an user to enter a 64 char random string to log in is not very convenient and will certainly lead to typo errors.
Also, as I said :
"He also add that its clients have money and when something is wrong and they can't access their account, he want to provide a way to allow an immediate connection."
From my perspective, this is because its user's have money that security should not be an option and we should reduce risk their private data from being accessible. Not the opposite.
Am I the only one wondering why this request ? What do you think about it ? Is there an alternative I could provide to my client ? Or at least others argument to convince him that this is not a good idea?
Or at the opposite, is this request perfectly fine and I am being too much paranoid ?
Thanks a lot for reading, I'm looking forward to read your answers ! Apologize my English, I'm not a native speaker.
Top comments (4)
It really depends on the relationship you have with the client. That said, the customer is always right.
Warn them of everything that could go wrong with their approach in writing, and make them sign a waiver that they take full responsibility for anything that does go wrong.
If you flat out refuse to implement what they ask, they may just fire you, and hire someone else to do it... It'll still happen, and you'll be out of a job.
If they realize on paper that they may be setting themselves up for legal trouble (e.g. letting social engineers steal their customers' funds), they may give up on their ridiculous demands.
Thanks for the reply ! I think I'll go this way, writing all the red flags about this request and propose alternative as Brad told in his comments and see how it goes.
The temporary login feature seems like the best bet, how-ever making it a 64 character random string is overkill, something like 6 lower-case letters + numbers, or just a few numbers would be fine. The key to this security approach is basically anyone can remember a few numbers/letters, and it will only last a minutes at most to allow a user to reset their password to something else. This approach is exactly how a lot of 2 factory authentication apps work (short term 6 digit code)
Allowing people to reset their password over the phone is meh, as you said that means tech people know the user's password.
You should never break security protocols for any client, regardless of how much money they have.
A few years ago the FBI publicly made a fuss over Apple not creating them backdoor security keys for iPhones so they can hack into a terrorist device. The reasoning is simple, 1 backdoor in the wrong hands means everyone's security is worthless. Apple would not create the backdoor keys as their pure existence is a risk not worth having.
I'm sure your not Apple, and the client isn't the FBI, so in comparison your talking about pocket change, but still just as much risk to end user data.
Stick to your guns, do your job, and keep the platform secure. Your not paid to say yes, your paid to say no. You can get strong armed into doing this feature, and how far you take your stance is up to you, but I personally do not agree with the feature of allowing a user to change their password over the phone.
Thanks for the detailed reply ! I'm totally on your side about this. As I told above, I'll go on writing to client telling about red flags and propose him a system where we can generate a 6 char one time login link with a short validity period. If after all he doesn't want, I may have no others choice than doing as he request, even if it make me uncomfortable to do it but I don't have much decisional power so let's see how it goes.