Secure Transfer

Consider the simple case of a web application database that requires authentication. The challenge is to share this secret information in an efficient but secure way and to transmit it automatically at a later date. What is the best way to do this?

Three Approaches

Traditionally, you have several ways to manage secrets associated with an application. The oldest method is probably the use of constants in source code, such as:

var PASSWORD = 'sn4k3oil'

This method tackles the challenge of keeping secret information synchronized between all team members in a simple, although not secure, way.

On the one hand, anyone who has access to the source code is automatically in possession of the secret information – regardless of whether it is necessary or desirable. On the other hand, exchanging keys with this procedure can turn out to be a tedious process, because the source code has to be changed, checked in to a version management system, and redistributed each time. It also makes it difficult to use the same code in multiple environments, such as a development environment and a production environment.

These disadvantages need to be avoided in a more mature alternative by storing secrets in configuration files that are not checked into version control. If you use this approach, you can remove the constants from the source code, but you accept other disadvantages. Without version control, synchronization between team members that was previously feasible is no longer possible. If a team member wants to change their password, they need to inform everyone else about it and find a secure way to do so. Additionally, this procedure results in unencrypted files on clients and servers that users can forget.

Subsequently, a third method has been established to keep secret information away from both the local filesystem and the source code. This method uses environment variables, which are then read out, as in this JavaScript example:

var PASSWORD = process.env.PASSWORD

This procedure ensures that neither the source code nor the filesystem contains confidential information in plain text. Moreover, the code can be configured easily to run in parallel in different environments. However, using the application becomes more complicated – to start it, you must make sure that the values configured by environment variables are available in the run-time environment.

All three approaches presented so far each involve a compromise between the ability to synchronize secrets and secure storage. However, it would be best to use a method that provides a synchronizable and sharable, but nevertheless encrypted, storage space.

Each team member needs to be able to decrypt information from storage. However, this should not require a password that is shared by all team members, because it will cause problems when distributing and changing this password. However, a password-free solution is also possible and can even be built with a few open source tools.

A Trip to GnuPG

One of the tools used is GNU Privacy Guard (GnuPG), the implementation of a public key infrastructure (PKI). GnuPG is best known for encrypting and signing email. When you create a GnuPG certificate, you generate a public and a private key. Different operations of asymmetric cryptography are possible with these keys, and such a certificate includes a unique identifier – the GnuPG ID – used to reference a certificate securely, which will later play an important role.

Information encrypted by one person with the public key of a GnuPG certificate can be decrypted by another person using only the corresponding private key. If a certificate holder shares the public key with others, it is possible for them to send him or her confidential information in encrypted form. As long as the recipient does not share the private key, only they can read their information.

Pass the Password Manager

The second tool used for the intended method of sharing secrets is the Pass [1] password manager. It is essentially a wrapper around GnuPG that lets you encrypt files in a directory with multiple public GnuPG keys at the same time, thus allowing several people to access and decrypt the encrypted files simultaneously in this directory.

Pass uses GnuPG's capabilities to encrypt individual files for any number of recipients simultaneously. For this purpose, GnuPG initially encrypts the file itself with a symmetric key generated on the fly. This is then encrypted for each recipient with their public key and added to the header of the file in this encrypted form. After encryption with GnuPG, the file header contains the information for decryption for each recipient.

The directory containing the encrypted files can be managed, versioned, and distributed easily through a version control system. With the help of Pass, an encrypted pool of information is created in the following sample application without using a shared secret such as a password. Installing Pass is very easy with the distribution's package manager.

The example in this article is a status page that interactively shows statistics for a specific GitHub user and requires a GitHub username and API token, which is the secret information that needs to be protected.

The application itself is written in JavaScript and hosted on the Heroku (Figure 1) Platform as a Service (PaaS) [2]. Because the example uses the existing infrastructure, it can focus on managing secrets.

Figure 1: Dashboard of the newly created Heroku application.