Sharing Passwords

Users sharing passwords is a practice that leads to a tremendous number of information security breaches. It is also quite common, occurring in virtually any company that does not have a robust policy prohibiting it. The scope and impact of the problem is growing given the vast number of login accounts users access for work in the modern cloud era.

Why Users Share Passwords

Users share passwords either on their own, or as directed by management, for just a few basic reasons.

  • To share internal resources conveniently with members of their team, instead of taking the time to set up separate user accounts.
  • To share resources available online with team members or outside the company when they don't know or care how to share the resource properly (that is, by setting permissions and sending invites to access the file, so each team member or outsider needs to authenticate with his own password).
  • In case of emergency—users who wouldn't normally be allowed to log in to a given application, such as the accounts payable system, might be given the password to that system by the person responsible in case the responsible person is out unexpectedly.
  • A worker was denied permission to a file by management or the file owner, but a member of her team decides she should access the file anyway, so he gives her his password.

Employees sharing passwords

Why This is Pernicious

Here are the reasons why it's dangerous not to prohibit password sharing by your users.

  • More access may be granted than intended. Users very often are little aware of what can be accessed with a given login and password. Users get prompted for passwords at various points of their day—when they first open their computer, when they open their browser and access e-mail, etc. Some users hardly ever enter passwords, as they are all saved in their device or web browser. IT support providers well know that it's common for users to mix up one login account with another. So when a user tries to share a password, it's quite possible for him to provide access to the wrong resource. Here are some examples:
    • Someone tries to share a password to a storage account where there is a file with a company contact list, but instead sends a link and the password to an online application that includes the accounting system.
    • The user correctly provides access to the file-sharing system, but doesn't realize those who get the password will see everything that this user can see, including files buried deep in the folder hierarchy, which might include sensitive company information such as financials or human resources data.
    • A user calls in from home to give the password for his computer to some people working after-hours so they can get to a file on his desktop, forgetting that his browser has passwords saved to a vast array of websites and online resources
    • A user shares his password for the e-mail system so someone can get in and see his calendar or contacts through a web browser, not realizing that the login account for this is part of the company's identity management system which grants Single Sign-On (SSO) access to a range of web-based applications with sensitive company information.

    Unauthorized access

  • If you allow sharing, you probably allow password resuse, meaning more spillage. Even a small company should be cognizant of the insider threat. So if your accounts payable manager shares a password for a simple online file storage site with a co-worker to share a file, that co-worker might try using that password to log in to your company's accounting system with the AP manager's account. If your AP manager had set the same password for his accounts on both systems, now you have someone in your accounting system who never should be in there, and nobody even knows.
  • You cannot enable multi-factor authentication. Some systems may be configured to require that a user prove he is in possession of something physical, in addition to typing the password, in order to log in. Typically, the system will send a temporary code to the user's mobile device for each login attempt, and the user gets in after typing in that code (in addition to the password). This is called multi-factor authentication, and it's a good idea to enable this where possible. If users set themselves up to log in with the same login account and password to a given service, then multi-factor authentication will usually have to be disabled, since it's generally designed to work with one device per login account. This means anyone, anywhere, can log in with the password alone, making the account less secure overall.
  • If users share passwords, they most likely use insecure communications to share the passwords (such as by e-mail), possibly exposing the passwords to people (inside or outside the company) they didn't intend to have them. We can make this assumption because if a user never received instructions not to share passwords, or does it despite policies prohibiting it, this means ignorance or deliberate disregard of secure practices is the norm at your company.

Even if you trust your users to be cognizant of the above potential spillage scenarios, consider which of the following is the prudent way to manage information security risk:

  • Counting on users never to make a mistake in a permissive environment, or
  • Establishing and enforcing sound security practices where such problems are systematically avoided as part of your business operations.


Multi-User Business Applications

Two types of controls enable visibility and governance by management over password sharing on multi-user business applications:

  1. Administrative controls, through policy and procedure. Exactly what these policies and procedures are will depend on your company's makeup and requirements. At a minimum, they should require that each user have a named account only for that user to access any resource. This will be effective only if all system administrators and users are aware of this, and you have systems in place to facilitate and encourage compliance. You may consider having employees and contractors sign system usage agreements establishing penalties for sharing passwords, understanding that the effectiveness of this will depend on your company's ability to discover violations and willingness to impose the designated punishments.
  2. Technical controls. SSO and multi-factor authentication using devices the company controls can prevent one user from logging in with another's password. Auditing systems can detect when a user account is used to log in from a device owned by a different user, or from a location where that user is not known to be.

Password management systems exist, some of which are quite sophisticated. Some can log users in to resources through a web browser extension using a shared password in a manner where the user can't even see the password. It can also allow an administrator to change the shared password and reshare it with everyone but one person, for a modicum of individual control. However, these systems should only be used in limited circumstances and controlled by specific designated administrators as described below. Otherwise, users will fail to embrace the concept of the integrity of individual user logins, which will encourage poor security practices.

Software Development and Testing

Software developers often require login accounts for automated processes, or regular user accounts for testing the user experience. The software development team tends, of course, to share the passwords, which are often simple. This is another common means by which infiltrators get in.

These accounts should be handled the same as for regular user accounts in standard business applications. That is, each account is controlled by only one developer, the developers or quality assurance engineers may not share passwords for these accounts (even with each other), and the accounts should be disabled or deleted when no longer needed.

Other Applications and Resources

Some systems may not be amenable to setting up accounts for each user, for various reasons. For example, social media accounts are generally designed primarily so that each account is tied to an individual for personal use, so assigning a team to manage your presence on a given platform seems to require password sharing. Other systems, such as a business web site hosting account or domain name management system, might be expected to support separate user login accounts for those who will edit the website content or manage the domain names, but often they do not.

When such systems are encountered, consider alternative providers, because this missing feature indicates the developers did not integrate security best practices into the design of their applications, meaning the user login accounts issue isn't the only security flaw you can expect to encounter. If there is no other alternative, you should not keep sensitive information on there, and you should devise additional, customized administrative controls and accountability to ensure the accounts are not misued. Unfortunately, a social media account is sensitive by nature, not due to confidential information, but because of its being the public face of your business. And your domain name registration management system is about as sensitive as anything can be, given your entire online presence (web and e-mail) depends on it.

Issues of Cost

In our current era of subscription services, many applications will incur increased monthly licensing fees for every additional user account created, which may put pressure on managers to approve sharing of passwords against the advice in this article.

Paying for a subscription

Whether this is a good idea points to the necessity of every business implementing an Information Security Program, which, when risk management and business impact are properly quantified, will either demonstrate why the additional cost is a valuable investment, or prove that the potential cost of a breach is less than the cost of the recommended extra user accounts. To learn more about implementing an Information Security Program, visit the J.D. Fox Exec website (opens in a new tab or window)

Password Sharing is the Only Option

When sharing a password is the only option, do the following:

  • Set up a separate resource for sharing the credentials, such as password-management software or an online service, or even simply a secure file in a shared folder.
  • Ensure this resource is accessible only by the users who should have the information, that they each use their own named login accounts to access it, and that an owner is designated who will manage the permissions to the resource. So if someone's access needs to be taken away, the owner can change the password on the protected system, and remove the ability of that user to access the file or app that shares the password.
  • Finally, if supported, enable audit logging in the protected system to be able to track when and from where a user logs in, so that, to the extent possible, individual users can be related to actions taken in the system using the shared password.

Regardless of how you manage it, the main takeaway for accounts where sharing passwords is the only option is this: Do it only when there is no other option. Once you start allowing exceptions for convenience, then password-sharing will eventually become the norm for everything, including user-level applications or file-sharing systems for which this should never be allowed.


Access to your company's Wi-Fi signal represents a final special case we'll discuss in relation to password sharing.

User connecting to Wi-Fi

There are options to limit Wi-Fi connectivity to designated devices only, or to require a user name and password for each user to connect. But, these are relatively difficult to implement and maintain, and are rarely seen in small businesses. And, network communications security is a different beast from application-level logins that are the primary subject of this article. So, until your risk assessment indicates the need to enforce individual logins for the Wi-Fi signal, most likely your network password can be shared without introducing undue risk, so long as you implement best practices and sound configuration management for your network to prevent intrusions into your servers and storage devices.


Trying to manage all this on-the-fly can be overwhelming, and so the whole issue is likely to be ignored in favor of focusing efforts on your company's core operations. The best way to handle this is to implement some sort of comprehensive tracking of your user login accounts and the capabilities of your applications, and develop and enforce appropriate policies to protect your sensitive information and control the integrity of your logins. And the best way to do this is to create an Information Security Program.