mjhjmtu

Alice and Eve work for Bob. Alice is a very good worker who does exactly what Bob asks her to do. Eve is a criminal mastermind hell-bent on destroying Bob's company.

Alice and Eve both share the same account.

Eve logs into the account and uses it to sabotage an important business process. The audit log captures this action.

How does Bob know who sabotaged his company? He has to get rid of the bad actor, but can't fire both of them, because his company depends on the work that they do. He could fire just one, but he has no way of knowing which one is his friend and which one is his enemy.

If Alice and Eve had separate accounts, Bob could be sure that Eve was the one who did the sabotage. Eve might even avoid doing the sabotage, if she knows her account will be audited and she will be caught.

EDIT: Adding from comments:

If Eve quits, you now need to reset the password on every account she had access to, rather than just disabling her personal accounts. This is much harder to manage, and you will miss accounts.

Additionally, it removes your ability to have granular control over access. If Alice should be writing checks, and Eve should be signing them, you essentially have no technological way to enforce that if they share the same account.

Also, it makes it harder for a given individual to notice malicious changes to their environment. Alice knows what files are on Alice's desktop. Any new files will likely raise a red flag for her. Alice doesn't know what files are on Alice and Eve's shared desktop. It is likely new files will be met with a shrug and an assumption that another user put it there, not a malicious actor.

Real story, happened at a friends workplace (jurisdiction: Germany):

A coworker of his rudely insulted clients via her company e-mail. She was fired for this. She did go to court. There, her lawyer made the court aware of the fact that the employees shared their passwords (for instance, for answering a client´s mail in the absence of a certain colleague).

The Judge ruled that there was no good proof that that the person in question was really the one who sent the insulting e-mails. The person had to be rehired and compensated for the lost wage.

Morale: One function of user accounts is to discern users from one another, to make their action audit-able. Only private accounts fulfill that function.

You should use separated account in all contexts (security on the top).

Adonalsium example show you because it's required.
There are some rare situations where it is "not possible" or "not usefull" ...

Examples:
"not possible" (legacy protocols/applications)
"no relevant" (anonymous actions)

If it is no possible, but you need to identify, you have to mitigate the risk adding more source informations as possible (e.g. connection info, connection time, etc ...)

You can check ISO 27001 Risk Assessment Methodology, ISO 31000 Risk management as starting point to answer to your question "Why avoid shared user accounts?"

The typical answer is accountability, traceability, etc; In other words to be able to know who exactly did what.

A shared account has n potential people doing something but all that you have points to one account doing that thing.

This problem is usually lifted by making sure someone is legally responsible for the activities of this account. This may or may not be feasible, and you may not have someone taking responsibility for the actions of others.

This problem often occurs when you outsource some monitoring activities - the account which does the monitoring tasks should be contractually in charge of that company, which is responsible for its actions.

If you cannot assign a responsible person, it is then up to management to make a decision based on the risk: not having a service vs. not knowing who does what with that account.

Best practices are nowhere "defined", that's what the term means. A best practice is simply an established way of doing things that most people think is the best way.

It goes the other way around. Once a "best practice" is dominant, usually someone on a standards board decides to put it into some ISO or other norm. It then rests there, usually without explicit reasoning, or a circular reasoning pointing out that this is best practice.

The reasons for this particular practice are likewise practical ones. If Alice and Bob share an account and something bad happens, they will both point to the other person and you have no way of figuring out who did it. With personal accounts, they'll claim it was compromised, but then you at least have a single point to investigate further.

There are also explicit requirements for accountability in many sub-fields such as compliance, and they play into this.

I only know one exception to that rule. There is one single machine that is shared by several users, and the following assertions are all true:

• one and only one of those users is in charge of this machine at any moment


• the account can only be used on the local machine - disabled via network

This may happen on 7/7 24/24 systems. In that use case, you still keep an acceptable imputability by knowing the user that was present at a specific moment, provided you could set the above second rule. But in fact, it is equivalent at having an account with no password, and only using physical security.

Another issue not yet mentioned is that if someone receives notification that their account is being accessed or has been accessed at a time when they're aren't/weren't accessing it and wouldn't expect anyone else to do so, they're much more likely to sound an alarm than they would be if they thought that the account might have been accessed by someone whom they'd authorized.

Given that the number of cases where it may be necessary for someone to authorize someone else to perform some particular action on their behalf, it would be extremely helpful if services could at include a means by which accounts could authorize and revoke secondary credentials with limited rights. That would allow the system to report which credential was used to access an account, thus allowing someone to better distinguish expected from unexpected activity.

Here are a few bullet points for easier understanding and a quick review.

Accountability

Accountability is another important principle of information security that refers to the possibility of tracing actions and events back in time to the users, systems, or processes that performed them, to establish responsibility for actions or omissions.

Compliance

If you are going down the path to be GDPR compliance or most regulations you need to be able to define a line on where each account have access to.

Legal

In case of an audit, you need to be able to pinpoint the accounts which were compromised or was responsible for an action.

Manage and protect

To protect, manage and monitor account it's easier to have separate individual access to delete, modify and detect abnormal usage.

Even if you are not following any regulations you still should (recommended) to follow the "best practices" it helps your overall network process on a big scale.

In addition to the auditing issue that other answers point out, shared-user accounts are inherently less secure than a single-user account on the same platform.

If more people know the credentials for logging in, that account is less secure. You now have many more potential victims of social engineering attacks. Each additional person with access to account is another vector of attack against that account's security. As the saying goes, two can keep a secret if one is dead.

I'd also caution against the use of shared logins from a psychology standpoint. Besides just auditing/culpability concerns, shared logins also inherently mean sharing both the glory the blame. You could be dis-incentivizing personal accountability and work ethic. If it's a shared profile, each individual will feel less responsible for that account's security. After all, even if they do all the right things (like using a password manager and avoiding phishing email), what if their coworker doesn't? Why should they put in the extra effort when another person is just going to do the wrong thing anyway?

Additionally, I suspect that shared logins will have weaker passwords protecting the account. Trying to share a strong password and properly manage it across multiple people would be inconvenient. You'd likely end up with either the lowest common denominator for password weakness (CompanyName01?) or a password physically written down for all in the area to see.

As said by many, accountability, traceability, liability etc are the main reasons. There are a number of extra points to consider:

• How secret is the information that is accessed? As an extreme case, many public FTP servers use(d) a shared account "anonymous". And is the account that you use to access public www-servers (a non-authenticated account) not basically the same? What about WPA2 passwords?


• When you create a company policy, it is much easier to enforce "NEVER EVER share accounts", than "well, you should never share an account, but in some cases, like a read only account to not-so-secret information for a limited period between two people that work together, you might do that, if the real risk is low".


• There is also an administrative burden on shared accounts. An example already given is the need to change passwords when someone leaves.


• Some accounts need to be shared. An example is root on Unix/Linux. Yes, you will place a lot of restrictions on the use of root in production, like sudo with extensive logging and security monitoring, a password-vault etc., but it still is a shared account.