Shared Passwords Could Take Your Company Down

Recently I was watching a startup software company’s demo of their new product, of which they were extremely proud. However, as anyone knows who’s conducted a new product software demo, things usually don’t go smoothly. The software engineer who was trying to start up the demo had to go to a command-line window and repeatedly attempt to log in to a background software service. In order to do this, he had to repeatedly copy a password from a text file open in another window and paste it into the command-line window. The password was available for all to see. Even better, the demo is live on YouTube, so any hacker can find that password at his leisure.

This experience made me cringe. Obviously, a software engineer shouldn’t be displaying a password for the public to see. Some might say that leaking the password in question wouldn’t cause any harm, because it could only be used to access a software service running on this engineer’s laptop. You’d have to have access to the laptop before the password would give you any privileges. But such a dismissal misses several key points.

First, people re-use passwords. The password in question might also be in use to secure other more accessible and more valuable systems.

Second, people re-use password patterns. The password in question followed a common pattern for forming passwords. Knowing that this software engineer followed such a pattern would be a substantial help to a hacker committed to guessing passwords.

Third, and most disturbing, neither the software engineer nor any of his colleagues seemed at all disturbed by this practice of keeping a password in a text file and copying it about in public. That’s because, for those used to the current state of software security, it is standard practice for shared software services to be “secured” by passwords that must be known to multiple people. This common practice creates a prime target for hackers. Consider that, in the wake of the Equifax breach, it was discovered that one could gain complete control of the Equifax Web site in Argentina using the username “admin” along with the very guessable password “admin”. (See https://krebsonsecurity.com/2017/09/ayuda-help-equifax-has-my-data/.) No high-tech hacking required.

Secrets That Aren’t Secret

I’ll discuss more about the general weaknesses of password systems below, but the reality is that most systems will be secured by passwords for some time to come, so we need to make passwords as secure as possible.

The key mechanism that makes a password secure is that it is a secret shared by only two parties: the person who conceives of the password and the system secured by that password. Even better, the password can be encrypted with a one-way hash, so that not even the system knows the password, but only the person.

But as soon as some system has a password that must be known by several people, this key mechanism is destroyed. Further, imagine the poor software engineer who has literally a dozen software packages he uses, each of which requires its own password. Since the passwords must be agreed to by multiple people, and it would probably be unwise to make them all the same, they will probably all be unique. No human can remember all that. This is why there is a culture of writing down and sharing passwords, and a resulting culture that it’s not so important to keep passwords secret.

Anonymous Access

Another problem with shared passwords is that you can’t know exactly who is using the system. Yes, you might know the group from which a user comes—assuming the password hasn’t been shared outside the group—but you won’t know which member of the group is using the system. If there’s one malicious user in the group, the system can’t help you figure out who that is.

The Root of the Problem

This shared password culture has deep roots. The UNIX operating system—the great grand-daddy of the Linux operating system that runs most of the World Wide Web—was invented back in the 1970s. At that time, UNIX had just one user ID, “root”, that was empowered to administer a computer. System administrators would typically agree on a single password for the root user ID on all the systems they ran. They would carefully control its sharing, but it wasn’t even that uncommon for a non-malicious user to obtain the password in order to perform some key function. But someone with “root access” could do anything to a system, including steal all its data, run any software, or destroy the system completely.

Role-Based Authorization

The Linux operating system, along with other operating systems such as Windows, fixed this shared password problem a while ago. Rather than tying elevated privileges to a single user ID such as “root”, operating systems now tie elevated privileges to “roles”. A group of privileges is named after the type of role a user might be playing when he needs such privileges. For example, the “Backup” role might allow making copies of any data, and is expected to be used by a system administrator responsible for backing up data. The “Web Administrator” role might allow the starting and stopping of Web servers.

A person playing the “User Administrator” role can associate a user with some number of roles. To gain the privileges of the role, the user must log into the system with that password that only he knows, after which he can exercise his role-related privileges. The system knows at every moment which user is exercising those privileges, and can log that user’s activities for later scrutiny if necessary.

The problem we face today is that many software vendors, and the open source community, have ignored this very basic system of role-based authorization. For various reasons, none of which are excusable in today’s world, they create systems that have their own password schemes that are disconnected from the operating system’s role-based authorization, forcing the use of shared passwords, and creating a culture that accepts sharing as necessary.

A Future Without Passwords

There have been many criticisms of password-based authentication in general, and a few alternatives have been put forward, including multi-factor authentication. The scheme that might hold the most promise is self-sovereign identity; however, considering that that idea has been in the development stage now for nearly two decades, it is prudent to consider some more short-term solutions.

Immediate Steps

Fortunately, there are steps any company can take immediately in order to reduce the risks that come with password sharing.

1. Start a program of continuous education and awareness throughout your business of the dangers of password sharing and non-role-based authorization. Remember, it’s not just technical folks who share passwords. Explain that some systems might require password sharing, but that the company is going to do its utmost to remediate or eliminate those systems. Warn employees that the sharing of passwords is a violation of company policy and subject to disciplinary action, unless the necessity for sharing is with a system on the known problem list. Then, take action to reduce or control such cases, as detailed below.

2. Provide a mechanism to track cases where password sharing is taking place among employees, subcontractors, and/or customers. Common situations include logins such as “readonly”, “admin”, and “root”. Keep a list of such cases.

3. Where possible, use a system’s role-based authorization to eliminate the need for password sharing.

4. Where possible, make sure that software is configured to use an operating system’s federated authentication, and delete or disable any user IDs that are not tied to the OS.

5. For all situations where shared usernames and/or passwords are unavoidable, keep a record of those systems, and develop a rigorous process for changing such passwords on a regular basis, using a password manager for securing the record of those passwords, and logging when someone obtains a shared password for use.

Longer-Term Actions

If you are a CxO and have identified one or more commercially supported packages (including open source software) that does not support role-based privileges and federated authentication, you should be calling those companies to account for their irresponsibility. Remember, weak security endangers your entire business. Don’t let a vendor pass the buck to you when their software is at fault. Get a commitment from every deficient vendor as to when they will support role-based authorization and federated authentication—and don’t offer to pay for that, either.

If you are using an open-source package that doesn’t have role-based authorization and federated authentication, agitate within the open-source community to fix that. You might even have developers on staff who can address these issues. If it can’t be fixed, plan to replace the deficient software with more secure software.

If you take the actions outlined above, your company and perhaps the rest of the world will be safer from easy hack attacks that come from shared passwords. Don’t wait until your company is the subject of news articles and lawsuits. This isn’t hard to do, and you owe it to your business to follow through.

Ted Hills

As an author, speaker, consultant, and executive, Ted Hills helps businesses combine strategic goals with the latest data management technologies to produce solid results in realistic timeframes. Ted is both...

More About Ted Hills