Really, don’t do it

Today we’re going to go over credential sharing, the importance of avoiding it, and some possible methods for making sure it doesn’t happen.

Computer Security is a balancing act between ease of use, available time (I.E Money), and the desire to make sure script kiddies don’t run off with all your valuable business data.

I decided to write this article after seeing many of my clients sharing SSH Keys and otherwise ignoring basic security principles.

I’ll be paying particular attention to SSH keys and API Keys in my example as these are resources that are commonly shared between technical personnel. Some understanding of these subjects are required but I will attempt to offer simple explanations for someone unfamiliar with the subject.

Who is this for?

• You’re a person who often finds themselves sharing secrets (API Keys, SSH Keys, username/passwords, etc) with other members of your team
• You’re a (likely exasperated) operations team member trying to explain the importance of not sharing credentials with non-operations team members.
• You’re a small business owner (Likely without a CTO) trying to understand the implications credential sharing may have on your business.

What is Credential Sharing?

Credential sharing is a concept that is easy to understand.

It’s the exchange of privileged credentials (sometimes called secrets) such as API Keys, SSH Keys, and Usernames/Passwords between a privileged user (Someone who has access to a resource) and an unprivileged user (Someone who doesn’t have access to a resource).

Example:

John is the only developer on a project at Acme LLC. Acme LLC has a single system user for server management that is accessed by John using his SSH Private Key.

For the layperson: An SSH Key consists of two components. A public key, which is like a lock and a private key, which is the key that goes to that lock. Any resource you place the public key on can be accessed by it’s associated private key. It is always OK to share the public key, you should virtually never share the private key.

After some time, Acme LLC decides it wants to add another developer to the team, Jimmy.

When Jimmy is added to the team John provides Jimmy with his SSH Private Key instead of generating a new SSH Key.

There are now two people accessing the same user account with the same private key.

So what’s the big deal?

It’s a problem for a few reasons:

• With a single user being utilized to access the system, it’s difficult to determine who actually performed what action (For example, if Jimmy or John carries out a malicious action on the system).
  • Let’s assume John and Jimmy would never do anything malicious (They’re good guys). If the SSH Key is compromised (By one of those darn script kiddies), you can’t tell if it was Jimmy or John who was compromised because you’re only using a single account and a single key.
    • The person compromised might have a rootkit or similar on one of their machines that has the SSH key, in which case changing the keys would be useless without solving the underlying problem.
• Due to some organizational changes, Jimmy has to be let go from the team. At this point, anywhere these credentials were used has to be rotated. A new key must be generated and added to all the system and then distributed to everyone who needs access.
  • If you have a team of more than 2 people, this problem will become even more pronounced. You would be looking at interrupting the work of what are likely some of the most expensive personnel in your organization while you add and distribute the keys.
• If you’re sharing credentials in this manner, it’s also likely you will forget to rotate the keys. At this point Jimmy has a key that could still be used to access these systems past the period of his employment. Even if Jimmy isn’t malicious, you now have another vector for the key to be compromised.

In short, sharing credentials of any type in this manner is not only a major security concern, it can also waste the time of some of the most expensive members in your organization.

How can I prevent this?

As with many security issues, the answer can partially be solved by technology but the other (often more difficult part) must be solved culturally (By those difficult to manage people).

Culture

You want people in your organization to understand the dangers and you want them to know that the operations team is there to help. Inversely, you want an operations team that views themselves as an enabler of the business.

Nobody wants to communicate with this guy after all

• Go over basic security with organizational members to stress the importance of not sharing credentials (As well as the importance of security throughout your organization).
  • Be sure to explain the potential damage credential sharing can cause the business.
• Provide avenues for people to communicate with your operations team (Preferably via a set process) to request access to systems.
• Ensure your operations team is receptive to the requirements of the rest of your organizations.
  • If someone is authorized (At an organizational level) to access a resource, providing the credentials should be as quick and painless as possible (While still maintaining reasonable security)

Technology

Let’s continue with our SSH key example from earlier. We want to increase security while keeping the amount of friction to a minimum.

• Stop using a single account to access your servers. Each user should utilize their own system account.
  • Each user should also utilize an SSH key that they generate themselves. This key should preferably be passworded as well.
• Create an easy to utilize system for the creation of users and adding of public keys to servers.
  • Directory Servers and Identity Management Systems can provide for great granularity but can be rather complex to manage and operate. This include things like OpenLDAP, 389 server, and FreeIPA.
  • A simple option for AWS is a solution from Widdix that utilizes IAM Code Commit public keys. You can find that here. For organizations with simple requirements (And who use AWS) this can be a great fit and is absolutely better than simply sharing keys. The solution is easy to utilize and implement.
  • Alternatively, one can manage user accounts and keys using a config management system like Ansible.

Similar rules apply for other resources like API Credentials. You should have credentials for your dev, staging, and production instances and if anyone needs access to the same resources, they should also have their own keys generated.

Summary

Sharing isn’t always caring, particularly when it comes to privileged credentials.

After reading this I hope you understand the security/monetary implications of credential sharing and are equipped with some basic guidance on how to accomplish it.

If you’re looking for an experienced Automation Engineer/Linux Sys Admin to help whip your infrastructure into shape, I hope you won’t hesitate to schedule a short meeting to talk about how I can help (You can easily schedule at the bottom of this post).

Want to understand how I can help? Take a look at my article here.

Till next time.