In the life of many organizations, developers and operations people need credentials that they can use in case of emergency — when, for example, your external authentication services (either your multi-factor service or your internal directory) experience an outage. The existence of these accounts presents a problem, however: one of the best ways for an adversary to ruin your organization is to compromise the login credentials of an account that is on every machine in your infrastructure.

With teams becoming larger and more distributed, keeping the password in an envelope for one person to use probably won’t work in an emergency. And making the password easy enough to remember is definitely not secure in an age when your adversary can rent a password-cracking cluster for dollars per hour. We also want to trust our internal admins to do the right thing, but we should ensure that adequate technical controls are in place to enforce that. So what can we do?

How to Share a Secret

Back in 1979, Adi Shamir (the “S” in “RSA” for folks familiar with cryptography) published a paper titled “How to Share a Secret.” The problem Shamir was considering was presented in a combinatorial mathematics text:

Eleven scientists are working on a secret project. They wish to lock up the documents in a cabinet so that the cabinet can be opened if and only if six or more of the scientists are present. What is the smallest number of locks needed? What is the smallest number of keys to the locks each scientist must carry?

“A minimal solution uses 462 locks and 252 keys per scientist. These numbers are clearly impractical, and they become exponentially worse when the number of scientists increases,” Shamir wrote. Indeed, that is a large keyring. He would later go on and describe an algorithm called Secret Sharing that allows someone to break a secret into several “shares” that can be distributed amongst many people, such that when a certain number of shares (defined by the organization) are combined, they reveal a secret value and that if you don’t have enough of the shares, you won’t get any information.

We’ll save you the deep dive on the details - if you have an interest in polynomial mathematics, Shamir’s paper is short, and worth reading. What is exciting, though, is that we can use the solution to the “secret project” example to protect our Administrator Account. People have turned Shamir’s secret sharing algorithm from 1979 into libraries that you can use today to enforce that your developers or operations staff can only get your emergency account’s password if a quorum of them get together and agree to do so.

Sharing a Secret

Here’s a sample program written in Ruby that uses the sssa-ruby library we found on GitHub. In this example, we’re imagining that we have four staff members, and any two of them can get together and recreate the password.

#!/usr/bin/env ruby
require 'securerandom'
require 'sssa'
random_string = SecureRandom.hex
puts "* Random string is #{random_string}"
shares = SSSA::create(2, 4, random_string)
shares.each do |e| puts "* Share: #{e}" end
combine_shares = [shares[rand(0..1)], shares[rand(2..3)]]
puts "* Reconstructed string: #{SSSA::combine(combine_shares)}"

Our program generates a random string, separates it into four parts (these are the individual parts you’d distribute to your staff), and picks a random entry from the first two and the second two to combine them.

When we run this program, our random string is separated into four shares, and then reconstructed from a semi-random selection:

* Random string is 92b7d4bf87fd82916c2d234a3c1769ca
* Share: ZqjMrDRCN_hwgPrxe_zVLHkQ0QtZLKIwst6HlFu5HZ8=OEaUQ8CdEtFptF0Gm8_GzY2b5O1x6PV8DfWDZVyC-p4=
* Share: JcscmxQaO-wi7_5HvxoWIynYf9jik5jrQkGxC4jkAIg=u9Yy5iZe5NKBbxkQtTPTlvK0MZqQErX7Vugc8ghv6_4=
* Share: QDCcIDJu9T7wwFGtihj9INzmCZnFrMBGXwHvErjny04=RL3YiggPfDeDsobRG_d7DfGind3g1a7x1GMx00H_cks=
* Share: djKNQW9esYZyH2gIjWulP_muIJzbh_EL0UU9Dor4YcU=zvdasiwQxldYSawPc9FkXqJiLpV0VBWz2_Kl8v8Kjb4=
* Reconstructed string: 92b7d4bf87fd82916c2d234a3c1769ca

Now, before you go off and use this technique, you may want to consider a few things. You may want to explore ways to encrypt this secret so that only a named recipient can open it, or not even display the password to begin with and update the target system directly with your application. Because this involves a security-sensitive library, it’s definitely a good idea to have one of your security folks review the library and how it works. These exercises are left up to you. But even starting with our sample, you’ve gained the ability to enforce that using a certain password requires multiple people to begin with, which is a good thing.

Tying it all Together With Threat Stack

But now there’s another issue: You really only want the “emergency account” to be used in emergencies. How can you discourage the use of this account for non-emergency use? That’s where Threat Stack comes in. With Threat Stack, you can create an alert that is triggered when someone attempts to use this account — or when any action is triggered on its behalf. Simply make a rule of user = "emerg". Now when any event is triggered involving your backdoor account (named “emerg” in this case), you will see it in any of the services you’ve configured for alerting.

This was originally posted on the Threat Stack blog.