When is a group password for a closed circle of users acceptable?

Question

I am developing a tool for a company, that takes some technical data and creates PDF reports.

In the tool you have several text fields, which get filled by the database. If the user wants to, he can change the contents of the textfields. In the end, he presses a button and some reports get created, archived and send to the customer.

My boss made the proposal to just use a group password for everyone, so every user of the tool knows the password and simply has to enter his own username.

I refrained from this and told him, this would be convenient, but unsafe mainly for the reason of Identity theft: someone can simply enter another username than his and input the textfields with nonsense, that gets send to the customer, print a report 300 times, create the report 500 times, etc.

We discussed this a little bit further and after he realised, that an attacker indeed could do some damage, at least to the reputation, we tried to find a scenario, where such a group password would be acceptable.

This got me curious: are there environments or situations, where such a group password would be acceptable? Or will it always get shot down with the "identity theft"-argument?

Answer 1

This got me curious: are there environments or situations, where such a group password would be acceptable? Or will it always get shot down with the "identity theft"-argument?

Yes, I would always shoot it down with the impersonation argument.

The second argument against it is: What if access should be revoked for one user? You would need to change the password for everyone, which is inconvenient.

So when is it acceptable to have a group password? I would say when:

• actions do not have to be linked to one specific user. Ideally, this means that there are no users at all (alternatively, you may try to link users to actions in different ways, eg IP addresses, etc, but this will be more difficult). Otherwise, you will get problems when something bad happens, as blame can easily be shifted. You might have people accusing others of impersonating them, etc.
• and you do not need to revoke access on a per user basis or you have different means of doing this (only accessible from internal network, etc).
• and obviously all users should have the exact same rights. Otherwise, a user can just gain rights they shouldn't have by using a different username.

And even then, you still might have problems. For example, people might not feel as responsible for a group password as for a per-user password and might thus easier disclose it, making social engineering attacks easier.

So I think there are very few situations where this makes sense, and even then, there are downsides, and very little upsides (per-user passwords are not that much more difficult to implement or manage, especially when you have separate user accounts anyways).

Answer 2

It's not acceptable if you want to be compliant with regulations like Sarbanes-Oxley (SOX), which - among other things - mandates that individual users must be easily auditable.

It is fair enough (on a UNIX or Linux level) to have a group account for an application which may be assumed by an individual named user, once they have logged in (i.e. using sudo su sharedaccount), but it should not be possible to log in directly with that account. That way, it is still possible to see (via system logs) who logged in, at what time, and who assumed the privileges provided by that shared user account.