Should I know my users passwords so I can check they can logon?

Question

I have an issue with support for a system and I don't know what approach to take. It boils down to the question:

Should I know my users passwords so that I can check with certainty that a particular user can logon and there is not a problem with their account?

If I can view my users passwords I can logon as a particular user, but this ability to see their passwords 'feels' wrong and I'm sure that there is a better design to overcome this problem.

Environment:

We have a bespoke Java web application that supports users being able to log in only with the correct user id and password. A systems administrator is responsible for creating users (and also their initial password), but users can go to a settings page to change their password.

Our system stores the usernames and passwords but the passwords are encrypted. A Salt it also applied to the encrypted password. The goal here is that only the user knows their password. We don't want to know it and we don't want to be responsible for it. Hopefully we are following a good password strategy!

Problem:

Alice, a registered user, cannot login to our system for some reason. She gets in touch with support and complains that our system does not work. Often this is user error but we have to follow procedure and check that the system is running.

We can test the system with our own administrator accounts and see that the system is working fine. We can also look at Alice's credentials and see that her account is not disabled or locked.

But Alice insists that she has a problem and that our system is broken.

Since we do not have Alice's password we cannot log on as Alice so we cannot state with 100% certainty that her account is actually working. We cannot rule out that the account has not become corrupt in some manner.

So should we have a system where we can log on as a particular individual (Alice) and prove that her account is working?

We really don't want to be responsible for the users passwords, but without a user's password how can we have confidence that the system is working? I also don't want to get into a situation where we are asking the users for their passwords since they (probably) share these passwords with other accounts.

I need to present a strong case to management as to how we resolve this sort of situation. They are of the belief that we should know all of the users passwords to overcome issues such as these.

Advice please.

Exaggerating a bit: how would you feel if the all employees in your bank knew your password? — Luiz Angelo, Sep 11 '13 at 13:34
If your company controls / has developed the entire system, they should be able to build features; either more logging so you can see when an invalid login attempt is made, or a feature that allows an admin to log in AS a user, using their admin credentials instead of the user's password. Both are better than knowing passwords IMO, and the user isnt bothered. ( ie password reset ) — Philipp Gayret, Sep 11 '13 at 14:36
One additional point on developing a feature to allow admins to login as a user: when developing such a feature, you can also build in limitations that prevent admins from performing critical actions. For example, on a product site you would want to prevent admins from ordering products as a user. — Michael K, Sep 11 '13 at 15:22
And unless you have a key to Alice's house, you can't be sure that it's not her home router that's causing an issue with your site. — Joshua Taylor, Sep 11 '13 at 16:21
The very first thing you check in these situations is whether or not the user has capslock on. If they're using the correct password, that's the problem a majority of the time - it's so easy to hit accidentally, especially for non-power-users who use a mouse/touchscreen more than a keyboard — Izkata, Sep 11 '13 at 17:05
Could you overwrite the password with a temporaty password to prove the user his account is working and then enforce the user to change it at the next login? this way you don't have to know the user password but you can prove your point — Rémi, Sep 11 '13 at 18:09

score 33 · Accepted Answer · answered Sep 11 '13 at 13:30

33

You can replace the users passwordhash with a hash you DO know the password for, save the users passwordhash so you can place it back later and then login to the system with the users credentials.

answered Sep 11 '13 at 13:30

Pieter B

665
5
8

That is simple and brilliant! That's a really good suggestion – Sep 11 '13 at 13:40
That's what most website login systems use. "We couldn't figure out what your current password is, so here's a randomly-generated new one. Please change it as soon as you can." – Katana314 Sep 11 '13 at 14:28
10

I would suggest caution with this approach. If your administrators can arbitrarily change the password back and forth between the user's chosen password and one of their own, it's not much more secure than knowing the user's password outright, and with this method, a malicious admin would have the ability to persistently use a user's account for nefarious purposes without the user's knowledge. The only thing they can't do at that point, it attack other sites/applications the user may have accounts on with the plain text password. – Xander Sep 11 '13 at 14:30
3

@Xander I would suggest caution with malicious admins. In better words, if administrator can change arbitrary data in database (because he governs rights, so he can grant them to himself) he can do this, but he can skip this and do anything he wants. So he must be trusted anyway. But if temporarily switching password power is given to helpdesk drones (or other lesser admins) number of trusted persons can grow too much. If this is concern, auditing (and checking audit logs proactively) can be used. Combined with automatically alerting higher ups when this feature is used. – Alpedar Sep 11 '13 at 15:05
2

A variation of this would be to have a secondary, temporary password, while leaving the original password hash the same, and the temporary password can only be used once (ie on login - disable it). – Vlad Preda Sep 11 '13 at 15:44
2

@Xander: at some point, you MUST trust your admins. That's why they're admins. They likely have direct access to databases anyway. I see your point, and you CAN mitigate some of this risk by maintaining audit records which those admins do NOT have access to modify. But if you have trust issues with people who directly access the databases, there are bigger problems than the possibility that they're twiddling with individual users' passwords. – loneboat Sep 11 '13 at 15:52
1

@loneboat True, but being arbitrarily able to remove and restore password hashes is fairly extreme for a customer service scenario. Yes, you will have to place that level of trust in your DBAs. You shouldn't need to in your CS staff, which would have been a better term to use in my comment than "admin." – Xander Sep 11 '13 at 16:21
@Alpedar Agreed. See my comment to loneboat. Admin was a suboptimal term to use in my original comment. – Xander Sep 11 '13 at 16:22
Usually, this sort of admin-trust issue is solved by either-or-both: A) Making it impossible, even for admins, to affect the "last date password was changed" value, which could be a part of the password hash. Thus, they couldn't put the password back how it was. B) Keeping a secure log somewhere of all administrator actions, so that if something suspicious ever happens (even if you couldn't prevent it), you can hold someone accountable and fire them. – Katana314 Sep 11 '13 at 17:50
@Phil: you really think this is a good solution? Why would you want to have this ability? I wouldn't want anything to do with a system that would allow this. Not as a user and not as an admin. The cautions against malicious admins had another side: good admins can be accused of malicious behavior... Proving that you didn't do something is much harder than proving you did do something. – Marjan Venema Sep 11 '13 at 19:57
This would be a good approach if used in a debug environment where the admin can test different theories. Prod I wouldn't allow even admins to directly manipulate account data except through limited admin tools. But I'm going with user error. :P – Andrew Hoffman Jun 17 '14 at 15:21

score 11 · Answer 2 · answered Sep 11 '13 at 13:56

A Salt it also applied to the encrypted password.

I don't know what you mean by this. I dearly hope that you store your passwords hashed with a strong hash like bcrypt or pbkdf2 instead of encrypted....

I need to present a strong case to management as to how we resolve this sort of situation. They are of the belief that we should know all of the users passwords to overcome issues such as these.

Your system should be smart enough to differentiate between a failed login due to bad credentials or some other errors. If it isn't, you have quite a large problem on your hands... You are also presumably able to create dummy accounts to test if the system is working. You are also presumably able to reset the passwords at will so you can always apply that to Alice's account.

So no, there is no conceivable reason that you should know the user's password. You shouldn't be able to know the passwords anyway if you are hashing them according to best practices.....

score 10 · Answer 3 · answered Sep 11 '13 at 14:03

The solution used in Active Directory (Windows network) is the "force password change" flag. The sysadmin resets the password (so he knows it, temporarily) but a flag is set, so that the authentication systems forces a password change, by the user himself, upon first usage. The user is not granted access to the data until he has changed his password.

In your situation, this would mean that the sysadmin first resets the password with one of his choosing (without the flag), makes his tests, then resets the password again, this time with the "password change" flag, and communicates the new password to the user. The user then logs in and changes his password, possibly back to its previous value.

This method requires that the login method (login screen or page) supports password resets, or that you can internally flag an open session as "for password change only", preventing actual access to everything except the password change page.

Alternatively, a sysadmin could manipulate the database directly, in the following way: he first saves the hashed password (including the salt). Then he resets the passwords, and does his tests. Finally, he puts back the old hash value and salt, thus "reactivating" the user's password -- without ever learning it.

Note, though, that the password contents are a rather frequent source of impossibility to log. E.g. the user included an accentuated letter in his password, and now tries to use a different systems which encodes accentuated letters differently (when computers used code pages, such trouble was very common, but even with Unicode you can run into issues with combining diacritics). When the user's problem is such, then forcing a password reset is the right thing to do, and re-enabling the old password won't work.

Iszi · Answer 4 · 2013-09-11T18:01:50.553

You should never need to know or even have to reset the user's password in order to eliminate that as a possible source of login problems. Your application should be smart enough to tell the difference (and tell it to the user, or at the very least include it in the logs) between a bad username/password combo and other account issues like security lockouts. If it's not, you should fix this.

That aside, the option of performing an administrative password reset is definitely preferable over disclosing the user's password to the administrator. However, there are still a few more things that should be taken into consideration:

This action should always be logged by the application, and these logs should be regularly audited.
The application should enforce that the user change their password after an administrative reset, and users should be trained to expect this.
Some environments require that users have unique passwords across their last 10+ passwords, and administrative resets are not exempt to this policy. This means that, whenever you perform an administrative reset of the user's password, the user will not be able to use their old password again when they change it back. Many users will be unhappy about this.

Some have mentioned a third option that is essentially a "sanity check" against the system: Create a dummy account and verify that the system is permitting that account to login. The flaw with this is that it is simply redundant. If the dummy account can't login, then chances are that the system is rejecting logins for a lot more than just one user - and you'll probably know this already before you're done testing the dummy account.

Another option mentioned is to manipulate the password database directly, such that you store the user's password hash outside of the database temporarily and manually replace it with the hash of a known-good password for testing. This is non-optimal for a couple reasons:

Front-line techs should not have this sort of access to the password database. It's a generally unnecessary increase in risk to the database. Thus, this sort of action should require escalation of a ticket that (most likely) should be able to be handled via other means by a lower-tier group.
This bypasses the application-native password reset functionality, which opens up the possibility that other standard procedures and security requirements (e.g.: forcing the user to reset their password after an admin has changed it, password history enforcement) may also be skipped.

As for reasons disclosure of user passwords in general should be avoided, there are a few attack scenarios to consider in the casse of a tech gone rogue:

The attacker may use a victim's credentials to gain and abuse privileges that their own account does not have.

An attacker who has privileges necessary to conduct a desired malicious activity may still use a victim's credentials instead so that the true source of an attack cannot be easily (and, perhaps, cannot at all for legal purposes) be identified.

Abuse of user credentials may not be limited to just the one system/application, nor even only to systems/applications owned by the company. Since users very often reuse passwords across different systems/applications/environments an attacker may, for example, take the credentials for your company's personnel directory and use them to gain access to HR or financial systems, or to victims' Facebook, Twitter, or online banking accounts. (Thanks to @Izkata for the reminder on this one.)

TL;DR: You should never ask a user for their password, and users should be specifically trained to reject such requests - this is Security 101. There are too many other mechanisms which should allow you to troubleshoot user account issues without disclosure of the user password, and the risk if the passwords are misused is far too great.

The application should be able to tell the difference between a bad username/password combo and other user account problems, and users (or at least administrators) should be able to see this. Even absent this, administrators should already have a mechanism by which the password can be reset to a known value for troubleshooting purposes. As a last resort, if it's absolutely necessary that the user be able to use their old password when possible, a direct edit of the password database (where passwords are stored in salted, hashed format) could allow an administrator to test a different password without losing the user's existing one and without actual disclosure of the password itself.

The reason to disallow disclosure of passwords is simple. Once an account's password is known by more than one person, all accountability for that account's activity goes out the window. Its credentials may also be re-used in other places, some of which may pose even higher risk to the organization either directly via loss of funds or IP or indirectly through bad PR when a successful attack (e.g.: compromise of PII or hijacking of high-profile social media accounts) becomes publicly known.

TL;DR of the TL;DR: There's really no good reason to allow system administrators, much less help desk personnel, to know end-user passwords. There's too many ways to work around needing this, and if the application is designed so that there aren't then it needs to be redesigned. There's also way too many good reasons to forbid disclosure of user passwords to sysadmins/help desk people.

3) A malicious tech could use the password on Facebook or other sites, as a lot of users (against advice) use the same one — Izkata, Sep 11 '13 at 17:11
@Izkata While a very fair point, that represents more of a threat to the users than to the organization (though eventually it will probably come around). The potential for misuse of passwords on the company's own systems is much more likely to grab management's attention. — Iszi, Sep 11 '13 at 17:41

score 3 · Answer 5 · answered Sep 11 '13 at 13:59

You should be able to tell the difference between a bad password and a lockout.

The easiest thing to do here is to send her a password reset link (with a token in the URL) so that she can change her password. Or, change the password to a random one (Use an admin form if you have one, otherwise manually update the entry in the db with a new salted hash) and send it to her. Ask her to immediately change the password.

Another option (which will help you debug) is to set up a simple page which accepts the plaintext as input and validates it against the salted hash server side. No bells and whistles of the layered application; a simple script that checks. She may well have forgotten her password, and this is the easiest way to check.

You should never put the user in a situation where they have to tell you their password. Most use the same password everywhere, so they may not be comfortable with letting that bit of knowledge out.

Tom · Answer 6 · 2013-09-26T12:51:03.457

3

Often we have a situation where a customer is experiencing a particular problem or is unable to perform a particular action on our online web interface (our system has a lot of exceptions and special cases due to the willingness of managers to bend over backwards for some of our bigger clients).

In these situations we have a mechanism where a technician can request access to the users account (via an emailed link that the customer (and one of the support managers) must follow and approve) which will allow a technician to switch to the customers account for a short period of time. During this time all changes are logged and reported back to the manager.

Since this is handed on the backend it doesn't require our tech team to have access to the customer emails or require our customer to disclose their password to our tech team. It also doesn't require the customer to reset their password afterward.

edited Sep 26 '13 at 12:51

answered Sep 11 '13 at 14:41

Tom

131
4

That is the right approach. Have a code that a customer can type *on the main page of the site* which will take the customer to a screen of the form "XX wants to log into your account YY. Type your account password if you wish to allow this". Customers should be told to get to such a screen via the site's main page, and distrust any pages of that form that aren't reached from the main page (I've had a bank request, via non-secure communication--that I supply username and password to a site in a domain I'd never heard of; I was quite surprised to discover--after ignoring that request... – supercat Aug 25 '18 at 18:52
...for a couple months--that it was actually legitimate [i.e. the bank really was requiring its customers to throw security out the window]. Even at the user level, many services should provide more means via which users can be granted temporary restricted access to some resources owned by other users. If users need to do something that can otherwise only be accomplished by sharing passwords, that's what's going to happen. – supercat Aug 25 '18 at 18:55

score 2 · Answer 7 · answered Sep 11 '13 at 17:04

I have a couple of systems that over time (as I learned more appropriate control approaches) have different ways of handling this same problem. On my oldest systems I use an approach already mentioned: Bob (the admin) save's Alice's password hash and replaces it in the dB with his own; Bob then logs in using Alice's user ID and his password. Down side is that any logging or audit control shows that Alice is logged in and performing actions. Also you have to only allow VERY trusted users work on these problems since they are masquerading as another user.

My more current applications separate out the user credential from it's permissions (nominally a totally separate table that links via each user's GUID for their user entry in the dB). I also have a support level procedure that clones a person's permissions and labels the cloned set as belong to Testing Tim (a fake account just for testing). This way Bob can get in and see exactly how Alice's permissions are allowing her to work, all while creating audit trails as Testing Tim. This also means that Helpdesk Hank and even IT Intern Ingrid can follow my procedure and perform the same tests.

NOTE :: When someone follows my support procedure it first clears all existing permissions from the TEST account, changes the password to a random password, emails the Alice user that we are cloning her permissions, then applies the cloned permissions. The audit logs also record which support user performed this process; that way if Testing Tim does something the log also shows who had the current password for the test account and what permissions they were supposed to be emulating. And at the end of the day (23:59 UTC actually) the permissions for Testing Tim are blanked again. (a check-in/out process would be better, but I haven't done that yet)

All in all, this method has proven the best for compliance and auditing as well as overall security. Any of my support crew can emulate any other user, but the user knows when they do, it is audited as "testing account" and who has that password, and it clears every day.

Nice approach! I especially like the logging of which support person cloned Testing Tim! — Andrew Neely, Sep 11 '13 at 18:09

score 1 · Answer 8 · answered Sep 11 '13 at 13:27

In such a case I would use something like this procedure:

Admin has a reset password option. In this case (and only then) he gets a new randomly generated password which he can use to test the account and then mail to the user. If any possible this password should be valid only for a single login (or short time period) so the user is forced to change the password again.

Otherwise if you are sure your system works if password is correct, you can use the common procedure that many web sites follow when the user forgot his password. Send an email with a unique link to reset password.

score 1 · Answer 9 · answered Sep 11 '13 at 13:40

1

You might want to have an option to reset any users password from your site's admin console, then log into the account, do your stuff and once done send an email to the specific user with a token which they can use to reset their password again. But this sort of approach might require to re-design your application architecture.

If you are asking how to solve the issue with Alice in particular there could be an ugly fix. You can create a new password with the salt and update Alice's record with the new password keeping the original in some place. Then you login and check if what she is complaining about is true. Once done you just update the password with the one that Alice had given.

Please not this is NOT A RECOMMENDED solution and can be treated as an one time solution

answered Sep 11 '13 at 13:40

user2720864

111
3

I'm confused as to your "ugly fix". as Pieter B suggested the same idea above. I think this is a good idea - it's simple, works with the current existing system without change. Ok, if we have a mistake by the admin and "lose" the original password or forget to change it back then we have a problem, but management would mandate a procedure to follow for this situation, and the admin could follow it. Can you elaborate on why it is not recommended and what you think is wrong with it? – Sep 11 '13 at 13:45
Sorry I've not seen the answer by Peter ( probably I was typing and meantime it was posted ). However I still think this is a ugly fix as it requires manual intervention, you need to manually create, update the password (the user will have no clue about this).But it should be okay if you are doing it for one time. But if you are planning to handle such situation then you should design your application in such way. Like a notification to the user must be sent saying what action has been done against his/her account etc etc. There could be multiple way. – user2720864 Sep 11 '13 at 13:59

score 0 · Answer 10 · answered Sep 11 '13 at 15:23

I think the usual way to handle this is the classic "password reset" if the client cannot log in with "what they believe" the password to be then you help them reset their password. Either through a forgot my password link or changing it administratively to another password "Password1" or something a little more secure like changing it to their birthday and setting it to expire on first log in.

now IF they change their password and hit an error logging in with that or hit an error with changing, then there might be a problem with the account worth looking into.

score 0 · Answer 11 · answered Sep 11 '13 at 17:20

From a security perspective several of the answers given already are worrying.

Direct access to the database should not be a normal procedure for handling customer support requests. It risks data corruption by human error, it allows bypassing all application logic to protect data access, its just wrong.

Being able to replace the users password, with one known to the admin staff, access the account and then put the users password back in place is also worrying. It effectively allows admin staff to impersonate users with little chance of detection.

From a support perspective assuming they can access the service, the most likely reason why a user cannot login to the service when everything is working is that they have forgotten their password. Asking the user to follow the reset password process is probably the most appropriate first support action.

If it really comes down to the support person has to log in as that users identity, then the secure way to do this for the users password be set to a known password, for the support login to occur and to validate the account works and then for the user to then follow the reset password process to securely create a known password.

Should I know my users passwords so I can check they can logon?

11 Answers11