Often when working with clients I need access to legacy websites or services such as DNS providers and web hosting dashboards. Usually when this happens, I’m given the same credentials that circulate amongst the clients’ own staffs, using the same shared logins as they do. Now, I’m a trustworthy individual, but there are many reasons that have nothing to do with my trustworthiness that make this a bad idea.
The Problems with Shared Logins
Insecure password sharing practices and other security risks can plague your infrastructure when account credentials are shared amongst team members.
While it’s no longer the case, WordPress historically would automatically create the initial account with the username “admin”. Even though WordPress now explicitly asks for the desired username, many organizations that intend to share logins will still use some variation of “admin” or “administrator” for the master account. This makes the site a prime target for brute force attacks, which often use “admin”, “administrator”, or a variant of the site’s own name in their attempts to break into the site because of the frequency of this pattern.
When multiple people are using a common account, by necessity the common password needs to be shared too. This can lead to insecure practices such as sharing via Post-It Note, plain text email, distributed spreadsheets, or other easily compromised methods. Additionally, the passwords themselves are likely to be short and easily-memorizable, which goes against modern password best-practices.
Lack of Two-Factor Authentication
Two-Factor authentication—the practice of using a secondary, one-time password from a cell phone, for example—is possible when sharing common account credentials, but it’s extremely cumbersome, and unlikely that an organization using shared logins would be taking that extra security step.
Every time your account credentials are shared among a team, you’re increasing the possibility that one of the trusted members might do something harmful—intentionally or through an honest mistake. And if you need to change credentials quickly because of a bad team member (or a team member that inadvertently compromised the security of those credentials), you’ll need to quickly change the credentials to the account and then distribute the new information, often by similar insecure means. Not to mention damage to the account in question that might need repairing.
There are a number of steps your organization can take in order to lessen the risks that come from shared logins.
Delegation of Roles
In systems that allow for multiple accounts to control the same information—content management systems, for example, and some of your more sophisticated managed web hosting providers—you can create individual accounts for every member of your team, complete with their own unique password, and delegate the required authority to them. This makes everyone in your organization responsible for their own online security and no one else’s, and also allows you to quickly shut out a compromised account without affecting the other members of your team.
Rule of Least Required Privilege
Not everyone on your WordPress site needs to be an administrator. Set the proper roles to go along with each team member’s role in your organization. Similarly, on your service provider’s site, only the account owner probably needs to be able to see all the billing information; the rest of the team can be assigned various levels of functional access without being able to see (and change!) things they shouldn’t.
Use a Password Manager
Insist that your team members use a password manager, or better yet, invest in an enterprise-level password manager for your organization. Not only do these systems store passwords in a more secure format than written paper or your computer’s sticky notes, they also let your team member generate long, nonsensical, and difficult-to-crack passwords that are unique for every service they have access to. Also, if you really must share account credentials among team members, doing so through a password manager is the most secure method to do so.
Sometimes, you just can’t avoid the shared login scenario. Not every service is up to speed on the need for individual accounts and role delegation. If you really must use shared logins, keep those account credentials as secure as possible and limit their distribution to as few people as possible. And petition your vendors to upgrade their own security practices.