Login for webapp, needs to be available for support staff

Question

I know the title is a little off, but it's hard to explain the problem in a short sentence.

I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".

1. Authorized licenseholders which does all setup themselves.
2. Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)

Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them. This is also how we do support: we login as them and then follow them along, guiding them.

Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.

So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.

Any suggestions?

(The platform is classic ASP... I said it was legacy...)

Answer 1

sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.

Answer 2

What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:

1. logged_user - the actual user who typed in his/her username and password
2. impersonated user - the user (1) is acting on behalf of

Everything you do is done with the impersonated_user's permissions and preferences. If you are not impersonating anyone impersonated_user=logged_user. This way you have to always log any operation with both "actual" username and "impersonated" username; for example:

2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'

Answer 3

Both options you present sound unattractive to me.

• A master password is probably even more dangerous than what you are doing right now

• Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.

I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).

How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)

Answer 4

I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.