March 12, 2015
As I've written in the past, security and convenience represent opposing priorities, and not just as far as computer systems go. For example, it would be a lot more convenient to get rid of the lock on your car or house. You'd never have to fiddle with keys again or risk locking yourself out, but the improved convenience would compromise security. On the other hand, having multiple dead-bolt locks on your door would surely improve security, but would be a hassle.
So, it's really important to keep security in perspective. There are plenty of Rumpus servers with highly sensitive content or that are attractive to potential trouble-makers. But there are also many servers that contain content that just isn't particularly sensitive. Other servers aren't considered mission-critical, and there is very little reason for anyone to bother trying to compromise the system. In these instances, convenience may well be a higher priority than ultimate security.
The "Server Security" article in the Rumpus package details a number of precautions server administrators should consider, especially on servers where the balance between security and convenience skews toward better security. There is one common security practice, however, that I always strongly encourage, even when convenience is king.
One User Account For Each Human
Allowing several people to use a single user account is never a good idea. It may seem convenient in some cases, but the security problems this practice creates are numerous and significant:
Problem 1: Loss of Accountability
As the administrator of a low-security server, potential system abuses may not be worth loosing sleep over, but it's important to understand that they can occur. By default, Rumpus maintains activity logs that record basic user actions. At some point, it's likely that there will be some form of abuse of your system, and the activity logs will be a key tool in discovering exactly what happened.
Unfortunately, if people share user accounts, there will be no way to identify the person responsible for the problem. If the abuse was accidental, there won't be any way to tell which person needs to be educated in the use of the system. If the abuse was intentional, you won't be able to hold the responsible person accountable.
Most importantly, there is no way of overcoming this problem after the fact. If users are sharing a user account, and that account is used to abuse the system, it will be impossible to reconstruct what happened later.
Problem 2: De-authorizing Users
Let's say that you've created one user account for a company, Acme Widgets, and all 8 people you work with at Acme share that account. What happens when one of those users leaves the company? Of course, you have to change the password for the account and communicate it to the 7 people who remain. But assigning users a new password is inconvenient in it's own right, and often doesn't happen. This problem is compounded by the fact that the person leaving the group has had access to the entire group's content and will continue to do so until the password is changed.
Problem 3: Maintaining Secrecy
Passwords are not a perfect way of authenticating users, even under the best circumstances. They can be forgotten, written down and misplaced, accidentally shared, etc. These problems are magnified, however, when many people share a single account and password. Passwords are secrets, and the more people who know a secret, the more likely that secret is to be shared.
Problem 4: Shared Accounts, Shared Everything
When multiple people share a user account, there is no way to make a distinction between those people. So, for example, if one person needs extended privileges or access to additional content, there is no way to grant that access. In this case, the administrator can create a new account for the individual with the needed access and privileges, so it's not a major problem. It's simply more convenient to just assign each user their own account in the first place.
For Rumpus administrators, a balance between security and convenience is important to find, and that balance will be different for every server. Assigning each person their own user account, however, barely nudges the convenience needle, while having a huge impact on security. A policy to make sure your server can uniquely identify your users is something every administrator should establish.