5 ms·

They mention having a "global" password that allows access to any user account. I've thought about doing this in the past, as a means of troubleshooting user su

They mention having a "global" password that allows access to any user account. I've thought about doing this in the past, as a means of troubleshooting user support requests, but haven't implemented it on any sites. Are there better ways of doing this, rather than having a global admin backdoor password? Is there a recommended "best practice" for logging in as a user, to see what they see when they use the app? I get a decent number of support requests where the user is seeing something in particular, and my being able to see it would be useful. At the same time, there's a pretty serious risk that's opened up by having this in place. Anyone have any thoughts / suggestions?

deleted 17y ago
[deleted]
nfriedly 17y ago
I have a "login as this user" link in my admin panel. Once I click it, I see what they see. The only downside is that I have to log out and log back in to get back to my admin account, but I usually keep myself logged in in firefox and do the testing in IE, so this isn't that big of a deal.
euroclydon 17y ago
This might be horrible idea from a security perspective, and if it is, please tell me, but what about allowing the hashed password in the password field, that way, you could copy it from the db, and sign in?
- charliepark 17y ago
  That seems like a really good way to handle it. Each account has a unique password, then, and it's only available to the admin. As long as the controller's coded well, this seems like a great solution. (If anyone has any concerns, I'd love to hear them.)
  - swolchok 17y ago
    Well, it doesn't sound bad, until you rephrase it to how it will actually be implemented: How about allowing the contents of the hash column in the database as the password? It only takes one incompetent engineer to sometimes store the raw password in the database, and it takes two to make that work to log in somewhere (presumably an easy defense is to only allow "verbatim logins" using something the same length as a hash).
    - brown9-2 17y ago
      Also it would defeat the purpose of having passwords hashed, because a data leak would then expose people's account just as if you were storing the plaintext password.
      - mbrubeck 17y ago
        At the one place I worked where this was actually implemented (spoof a user by entering a hashed password), it only worked from inside the firewall, to mitigate this risk. According to the interview, Facebook has similar restrictions on user spoofing.
  - ehsanul 17y ago
    There's a security issue with this idea obviously. If I'm not mistaken, the whole point of hashing passwords is so that a loss of the user database in some way does not compromise any accounts. You might as well store passwords in plain text if you allow hashed passwords as passwords. It might just be acceptable though, since almost nobody would guess that a hashed password would be accepted as a password. That is, unless they have access to the controller source code too, and check it out (as you'd assume since the database itself has been compromised). A better solution may be to create a second temporary password, hashed in another field in the database, and wipe it out when you're done. It's fine to use an extremely long master password too, making sure it's stored as a bcrypt hash or something. Just run the calculations to make sure that it couldn't be broken in 2^999 years.
    - 17y ago
- deleted 17y ago
  [deleted]
sriramk 17y ago
I think defending against internal abuse is always an uphill task. The key thing is to have auditability - store records of who accessed what and when and make sure those records can't be tampered with. The knowledge that that data is being generated acts as a major deterrent (apart from being a forensic tool)
Hexstream 17y ago
Seems to me the best way to implement the "login-as" feature is to make it possible for an admin account with sufficient privileges to just enter the name of any user to start a "nested session" from their admin account (password of the user you're logging in as not required) where they see everything the real user would see but the logging somehow remembers that this is a nested session. So you could differentiate between RandomGuy actually logging in, Hexstream logging in as RandomGuy and MetaNull logging as RandomGuy. No need to fuck with passwords, guys!

deleted 17y ago

[deleted]

nfriedly 17y ago

I have a "login as this user" link in my admin panel. Once I click it, I see what they see. The only downside is that I have to log out and log back in to get back to my admin account, but I usually keep myself logged in in firefox and do the testing in IE, so this isn't that big of a deal.

euroclydon 17y ago

This might be horrible idea from a security perspective, and if it is, please tell me, but what about allowing the hashed password in the password field, that way, you could copy it from the db, and sign in?

charliepark 17y ago
That seems like a really good way to handle it. Each account has a unique password, then, and it's only available to the admin. As long as the controller's coded well, this seems like a great solution. (If anyone has any concerns, I'd love to hear them.)
- swolchok 17y ago
  Well, it doesn't sound bad, until you rephrase it to how it will actually be implemented: How about allowing the contents of the hash column in the database as the password? It only takes one incompetent engineer to sometimes store the raw password in the database, and it takes two to make that work to log in somewhere (presumably an easy defense is to only allow "verbatim logins" using something the same length as a hash).
  - brown9-2 17y ago
    Also it would defeat the purpose of having passwords hashed, because a data leak would then expose people's account just as if you were storing the plaintext password.
    - mbrubeck 17y ago
      At the one place I worked where this was actually implemented (spoof a user by entering a hashed password), it only worked from inside the firewall, to mitigate this risk. According to the interview, Facebook has similar restrictions on user spoofing.
- ehsanul 17y ago
  There's a security issue with this idea obviously. If I'm not mistaken, the whole point of hashing passwords is so that a loss of the user database in some way does not compromise any accounts. You might as well store passwords in plain text if you allow hashed passwords as passwords. It might just be acceptable though, since almost nobody would guess that a hashed password would be accepted as a password. That is, unless they have access to the controller source code too, and check it out (as you'd assume since the database itself has been compromised). A better solution may be to create a second temporary password, hashed in another field in the database, and wipe it out when you're done. It's fine to use an extremely long master password too, making sure it's stored as a bcrypt hash or something. Just run the calculations to make sure that it couldn't be broken in 2^999 years.
  - 17y ago
deleted 17y ago
[deleted]

sriramk 17y ago

I think defending against internal abuse is always an uphill task. The key thing is to have auditability - store records of who accessed what and when and make sure those records can't be tampered with. The knowledge that that data is being generated acts as a major deterrent (apart from being a forensic tool)

Hexstream 17y ago

Seems to me the best way to implement the "login-as" feature is to make it possible for an admin account with sufficient privileges to just enter the name of any user to start a "nested session" from their admin account (password of the user you're logging in as not required) where they see everything the real user would see but the logging somehow remembers that this is a nested session. So you could differentiate between RandomGuy actually logging in, Hexstream logging in as RandomGuy and MetaNull logging as RandomGuy. No need to fuck with passwords, guys!