Why avoid shared user accounts?

Question

I know its best practice not to allow shared user accounts, but where is this best practice defined? Is it an ISO standard or something? What is the reasons to always create per person accounts?

For those of you answering in comments - please don't do that. I have deleted them. If you would like to write them as answers that would be very helpful. — Rory Alsop, Mar 02 '19 at 10:17

Monica Apologists Get Out · Answer 1 · 2019-02-26T13:39:20.210

147

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.

edited Feb 26 '19 at 13:39

answered Feb 25 '19 at 15:53

Monica Apologists Get Out

4,031
1
15
22

50

+1 Except that Eve, being a criminal mastermind, would have hacked in to Bob's account so he would have had to fire himself :-) – TripeHound Feb 25 '19 at 16:22
73

A more common situation: Eve quits or gets fired. Now you have to change the credentials for everything Eve was using (assuming you know that), you can't just disable Eve's account(s). – JimmyJames Feb 25 '19 at 16:41
10

Shared accounts also makes it much harder to detect when a bad actor has gained access to an account they should have access to. – JimmyJames Feb 25 '19 at 16:44
Added to body. I didn't add the part about account compromise because I think that applies to all accounts. If I'm misthinking that please let me know and I'll throw it in. – Monica Apologists Get Out Feb 25 '19 at 17:39
17

Even if Eve isn't out to sabotage the company, Alice and Eve's sharing an account also means that Bob can't give Alice additional permissions without also giving them to Eve. If Alice is promoted and now has access to data X, Eve gets it, too. – minnmass Feb 25 '19 at 19:10
1

@Adonalsium With regards to the account compromise, if I notice a file pop up in my personal directory, or pages in my browser history, or anything else out of sync with my account, since I'm the sole user that sets off a red flag. Even if I'm using a communally accessible directory, files I create have my owner id on them, and if things pop up under my name, I'd react. But on some of our test machines, there are some test accounts with shared login information, so when things pop up, I assume someone else with a valid reason created them, not suspecting that someone's compromised the account. – Davy M Feb 26 '19 at 01:39
The specific term for the desired state is [**non-repudiation**](https://en.wikipedia.org/wiki/Non-repudiation) - the ability to (with a high level of confidence) associate actions or changes with a unique individual. – TylerW Feb 26 '19 at 02:42
"If Alice and Eve had separate accounts, Bob could be sure that Eve was the one who did the sabotage." Assuming Eve was not able to obtain unauthorized access, of course. If Alice has her passwords sticky noted to her monitor, you might have problems. – jpmc26 Feb 26 '19 at 04:30
3

@jpmc26 This is true, but this is not specific to shared vs non-shared accounts. – Monica Apologists Get Out Feb 26 '19 at 13:38
It seems a much of this is mostly about sharing account passwords rather than merely allowing access through another account? You don't have to disable other people's accounts if their passwords weren't shared. – user541686 Feb 27 '19 at 01:21
In this example, Eve might be malicious or more likely clumsy. Who dropped the OrderEntry table? WTF guys?! – corsiKa Feb 27 '19 at 05:40
1

So, this is less of a theoretical principle and more a practical reality type thing, but it's also a lot harder to manage securely storing and sharing the credentials. If the password gets shared, the number of times in it's lifespan it gets sent through some channel increases, and so do the chances that someone will use an inappropriate and insecure channel to do so. – Iron Gremlin Mar 01 '19 at 01:07
"you will miss accounts": A while back I found out I had admin access (CRUD on all members, when I should only have been able to read my own records) to a 100 person org for two years after I left the company (that's when I discovered the mistake) and it was only removed after I informed them they hadn't revoked my credentials... – TemporalWolf Mar 01 '19 at 18:29
One reason is to not fail existing security related standards which REQUIRE the use of uniquely identifiable user accounts and minimizing or mitigating use of shared accounts. Example: PCI DSS for credit card processing. – HackneyB Mar 03 '19 at 00:54

Daniel · Answer 2 · 2019-03-02T22:31:58.627

30

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.

edited Mar 02 '19 at 22:31

answered Feb 26 '19 at 14:22

Daniel

401
3
4

7

It's a classic, in many country with many variation. You will find similar example almost everywhere. It's so mainstream it doesnt qualify for funny story in most French prud'homme (a French tribunal appointed to decide labour disputes). – xdtTransform Feb 26 '19 at 15:30
Off-topic: but that's just a bad e-mail set-up. Every email system around for the past 15-20 years supports delegated mailbox access, even Gmail and formerly-known-as-Hotmail support it. – Dai Mar 01 '19 at 00:54
@The D: Thers always a technical Solution, but in this case the Company chose to let the employees just share their Windows password and this is the result of that policy. – Daniel Mar 01 '19 at 15:46
@TheD: The way I read that sentence is that everyone had individual email accounts but shared passwords with friends so their friend can answer their email if and when they are not available (on sick leave etc). It's bad policy and enforcement, not bad email setup – slebetman Mar 01 '19 at 15:58
3

@slebetman: I think the moral of the story should be: One function of user accounts is to discern users from one another, to make their action audit-able. Only private accounts fulfill that function. – Daniel Mar 01 '19 at 16:03
1

This reads more as a story than an asnwer – northerner Mar 02 '19 at 04:43
1

@Daniel That is _the_ answer! Everything else on this page is a distraction. – Lightness Races in Orbit Mar 02 '19 at 16:36

score 15 · Answer 3 · answered Feb 25 '19 at 16:37

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?"

ISO 27001 doesn't detail any RM methodology, it basically says "hey, RM is a good idea, you should have one". RM is detailed in 27005, but again on a high level without a specific methodology and only listing a few examples (and bad ones at that!). The 27k is really less than helpful in this regards, I'm having a hard time in my risk management courses to teach people proper risk management, even if they already know the 27k. — Tom, Mar 03 '19 at 08:51

score 9 · Answer 4 · answered Feb 25 '19 at 17:27

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.

score 5 · Answer 5 · answered Feb 26 '19 at 11:04

5

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.

answered Feb 26 '19 at 11:04

Tom

10,201
19
51

2

It's not rare for someone (or an organization) to write and publish something that documents best practices, though. That doesn't *define* them, and it can be controversial which practices should/shouldn't be included in this document, but not sharing accounts is clearly agreed upon and the OP is simply asking if anyone has written that down someone. – Peter Cordes Feb 27 '19 at 09:00
2

No, OP specifically asks if it is defined, e.g. in an ISO norm. My answer is that if it is in the ISO norm, then it is there because they considered it a best practice, not the other way around. – Tom Feb 27 '19 at 15:47
I'm glad someone actually addressed the standards part of the question. PCI DSS Requirements 8.1 and 8.5 refer to using unique accounts and not using shared accounts. NIST SP 800-53 also has sections on identification and use of shared accounts. – HackneyB Mar 03 '19 at 00:52

score 4 · Answer 6 · answered Feb 26 '19 at 07:08

4

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.

answered Feb 26 '19 at 07:08

Serge Ballesta

25,952
4
42
84

Typically in this set up best practices are to use a management software to roll the password every few hours, and have staff check out the shared password to their personal account as needed. – Monica Apologists Get Out Feb 27 '19 at 20:08
Please also make note that the approach you state here has 0 advantages over just properly configuring credentials for multiple users. If you can learn how to configure local-only access you can learn how to configure sudo properly. – Iron Gremlin Mar 01 '19 at 01:12

score 4 · Answer 7 · answered Feb 27 '19 at 20:47

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.

This is just a summary of other answers and nothing new? – schroeder Feb 27 '19 at 21:50 — schroeder, Feb 27 '19 at 21:50

score 3 · Answer 8 · answered Feb 26 '19 at 17:30

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.

score 1 · Answer 9 · answered Feb 28 '19 at 14:17

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.

score 1 · Answer 10 · edited Feb 28 '19 at 19:42

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.

Why avoid shared user accounts?

10 Answers10