1

Brainstorming ways to share passwords without the users being able to see the passwords. In Windows we can watch/control when/what users do on corporate computers. There are some web services multiple users need access to that have shared credentials. Rather than continuing to share credentials for services where it is not practical for us to have multiple user/logins for a site, is there a desktop application that can be setup on Windows that can be used to populate login forms and login to websites without showing the passwords with the user?

Since we can easily monitor when/what users do on the corporate computers, the goal is to be able to setup a users desktop with buttons that log them into websites that have shared credentials. To know who logged in and when, we can review desktop session history. With shared usernames/passwords, we aren’t able to prevent users from logging into websites with shared credentials from personal computers and if the credentials are leaked, we don’t know who leaked it.

I’ve considered using:

  • Quickmacros and building custom task.

  • RoboForm and building custom task.

  • KeePassX with some custom scripting.

Are there any other security tools/methods for handling this?

jtlindsey
  • 225
  • 1
  • 10
  • 2
    Yes, tons. Cloud service brokers, SSO, Privileged Account Security software, Privileged Access Management software, etc. – schroeder Jan 30 '18 at 21:15
  • 3
    What you want is a login proxy service. The user logs into that with their personal credentials then the proxy service authenticates them and logs into the target on their behalf. – schroeder Jan 30 '18 at 21:16
  • In addition to the classes of tools refed by @schroeder you may want to look at a solution that logins in in some sort of proxy and then passes the cookie back to the user - essentially session hijacking. You have the proof of authentication but not the password to do authentication again on your own, the session can always be invalidated. – Eric G Jan 30 '18 at 23:01

1 Answers1

3

The easiest solution would be to refactor applications where possible, but if you cannot edit the source there are a few strategies:

"Middleman" password/account management solutions.

In this class of solutions, the actual password management is delegated to another service. The better solutions will be able to login to an application and change the password, then the password is changed by the application/service before each user logs in and is changed when the user logs out or time expires. In this way a password is produced for each individual and it has no value after the session because it has changed. If you want to research tools look for the class of "Privileged Identity Management" (PIM) tools.

Similar to a PIM solution, is a Privileged Access Management (PAM). Sometimes these tools are considered similar or a product may do both, but my definition of PAM is where the tool brokers the access for you. This article from Thycotic gives a brief look at terminology (warning from a Vendor)

Most of these services are designed for the OS level and are not always easy to configure with some type of cloud / SaaS service which has a workflow or 2FA.

Jump Box Solution

You may want to restrict access to authenticate to the service to a specific host. You then have strong authentication and logging on that host (maybe even record the screen). This may be sufficient for your needs depending on the apps and if you only need to do simple correlations to who was on the jump box to the application's logs. At the very least you can record all the activity. Some jumpbox+PAM solution may offer this through a web interface.

The weakness here is that you are not putting the control on the app, but at a lower level.

Proxy the authentication

If you are working with a popular cloud application, you may be able to find a CASB that you can put in front of your application and will enable the logging. The CASB may have the capability to do some form of PIM, pass a token, etc.

You may be able to setup some type of reverse proxy solution. OpenIAM describes such a setup for legacy applications - I have read about this before but we never got around to trying to implement it for a legacy application to which we had wanted to add SSO.

Note:

In your original post you talk about auto-filling forms. This still means the password could be intercepted or that two users could be authenticated at the same time if the web app does not prevent concurrent sessions. I would avoid anything that is like a end user password manager that just syncs the password files.

The ideal solution will make it so only one user can be on at a time and where an individual user either never sees the password of his version of the password becomes "one time" use.

Eric G
  • 9,691
  • 4
  • 31
  • 58