1

A company I work for wants to share a login to a sensitive application.

The application unfortunately does not support multiple users, so a username / password combo is shared between several people via a password manager.

We would like to setup 2FA for this account, but the implication here too is that everyone needs to share the same 2FA token.

The users want to do this by capturing a screenshot of the QR code during setup, distributing the code via Signal and store the QR code (in a second password manager, in case new people join the team). IF someone leaves, new codes get generated.

How reasonable is this?

Evert
  • 113
  • 6
  • "reasonable" is not a word that we can objectively evaluate. If you cannot stop sharing the account, then of course it is reasonable. – schroeder Jul 10 '18 at 19:15
  • @schroeder I can't objectively evaluate it either, that's why I'm here. – Evert Jul 10 '18 at 19:16
  • Then let me rephrase: what is the risk in sharing the 2FA token? – schroeder Jul 10 '18 at 19:19
  • I actually don't know. I'm not at all a security professional. I was worried for example that storing the QR code itself is a security risk in itself (maybe it's meant to be used once and discarded). Really just kind of looking for obvious gaps. From your first comment though, it sounds like this is a decent solution given my constraints. – Evert Jul 10 '18 at 19:23
  • Then your better question might be how to secure this situation given the constraints. – schroeder Jul 10 '18 at 19:28

3 Answers3

2

This approach addresses two of the known problems with shared accounts:

  • "The more people have a password, the more easily it leaks."
  • "Once a person leaves, the password needs to change for everybody."

It doesn't affect the third. Depending on the application, this may be more or less important:

  • "When the user makes a change, there's no way to tell which person did it."

If you're not deeply concerned about attribution, but feel it will be easier to force key changes and control key distribution under the new scheme, then yes, this is reasonable.

If you're hoping to address attribution as well, then this is not making a significant change.

If you can put your 2FA behind an application control that /is/ per-user, then you can come close to achieving all of them. People use their individual credentials to get the current 2FA code from a single central location, then use that code to log into the application, and by correlating the two sessions you can determine who was logged into the application for a given session. The code is always changing, and the 2FA device is centralized and not shared, so departing users don't have ongoing access. And with proper access control over access to the 2FA device, the leakage problem is lessened.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
1

If you can't avoid using a shared account, then what you propose is indeed a workable solution.

However, it may be possible to emulate separate accounts if you're willing to go through some more effort. Create some wrapper service that can proxy the target service. Create one account for each user, with 2FA as desired, within the wrapper. Whenever an authorized user authenticates to the wrapper, the wrapper then authenticates to the target and forwards the session back to the user. This way, only the wrapper knows the creds to the shared account on the target, and the wrapper can log what users did what using the target even though the target can't.

user3553031
  • 143
  • 1
  • 7
0

In simple terms use a Jump Server with 2FA / MFA (Multi Factor Authentication) in front of your application as a security layer. Hence each user must login using their own identity to the jump server and from there they could login to the target server.

By doing this you may identify the user with the session details on Jump/target servers.

This is a workaround only, not a perfect solution and you may refer below link for setting up jump server:

Jump Servers for security

Sayan
  • 2,033
  • 1
  • 11
  • 21