Product & Solutions
Resources
FREE TOOLS
Website Security Assessment SSL Certificate Checker Domain Expiry Checker HELP AND SUPPORT
Help Center Developer HubCompany
Developers universally share one essential tool in their arsenal: the command line interface (CLI).
Many development tools lack a graphical user interface (GUI) and rely solely on the CLI. Embracing a CLI-centric approach offers several advantages.
Proficiency with the command line enables developers to work more efficiently than GUI alternatives, empowering them with the invaluable capability of scripting.
This scripting prowess forms the foundation for constructing and overseeing software delivery pipelines and CI/CD workflows.
However, for many, there’s nothing more daunting than facing an empty terminal window with a blinking cursor awaiting commands, especially for newer developers.
It lacks the user-friendly UI guidance seen in GUI applications, placing the onus on developers to know precisely what to input. The responsibility of getting it “just right” rests squarely on their shoulders, and there’s a substantial learning curve to navigate, particularly concerning security.
One aspect that frequently receives inadequate attention during CLI mastery is local security, specifically concerning credentials—commonly referred to as secrets.
While secrets management might appear reserved for code repositories, runtime environments, and the CI/CD pipelines that drive modern application delivery, sound security practices should commence right at the developer’s “home,” which, in this context, means the terminal.
The initial step in safeguarding secrets within the command line environment is to conduct an inventory of potential existing secrets.
Secrets, in this context, encompass any sensitive information that, if exposed, could grant unauthorized access to systems or data—commonly referred to as digital authentication credentials.
These secrets generally fall into three broad categories: Passwords, Keys, and Certificates.
Passwords have long been a cornerstone of security, serving as the primary means for user authentication.
They are something you know and are synonymous with user access to systems. Securing passwords is paramount; storing them in plaintext within local files, for example, poses significant risks.
Insecure storage practices can expose passwords to unauthorized individuals who gain access to your local machine. While the ideal scenario involves memorizing all passwords, the reality of managing numerous credentials necessitates secure local storage methods.
Keys fulfill a similar role to passwords, providing access to systems and data, but they differ significantly.
Passwords are typically human-generated and designed for manual entry, often shorter in length.
In contrast, keys are algorithmically generated, longer, and more complex. They are not intended for manual entry or human access to systems.
Keys are primarily used to grant machines and processes access to other systems, unlock encrypted data, or perform cryptographic functions.
SSH keys are a familiar example, where public keys are shared with remote systems, while private keys are stored locally, and their security is paramount.
Certificates are a means of storing, transporting, and using keys.
They include keys along with crucial metadata like issuer information, purpose, and a signature for authenticity verification.
While SSL/TLS certificates are well-known for securing web communications, certificates are increasingly used for authentication.
Platforms like Active Directory offer integrations that leverage certificates for access control, reducing the need for manual password management.
Securing certificates locally may not always be straightforward, especially on centrally managed machines.
Developers must remain aware of stored certificates, implement safeguards against inappropriate sharing, and ensure the keys within certificates are not exposed, as this represents a potential security threat.
In essence, safeguarding local credentials—be they passwords, keys, or certificates—is an essential aspect of overall security hygiene in the developer’s environment, starting right at the command line.
Understanding what types of secrets to safeguard is essential, but equally critical is recognizing how these secrets might be exposed to malicious actors or rogue codes. Secrets can be compromised through various avenues, even on your local laptop.
They can be stolen from plaintext files containing passwords or stored keys. Furthermore, when connecting to remote servers via SSH, there’s the potential for unexpected access.
The SSH credentials themselves could enable unauthorized access and potential impersonation.
Here are some common ways through which secrets can be exposed:
Credential files provide a secure means of storing secrets away from version-controlled directories.
You can easily set file permissions using tools like chmod and programmatically access their contents. Managing a separate file for each credential can limit an intruder’s ability to collect them, reducing the scope of potential attacks.
However, these files carry the risk of storing credentials in plaintext, which can be mitigated with proper encryption.
Entering passwords or keys into a command-line interface is occasionally necessary.
The danger lies in the fact that any plaintext input in the terminal is stored as plaintext in your terminal’s history. All shells maintain a history, and if you use Bash or Zsh, your history is stored in a file like .bash_history or .zsh_history.
An unauthorized user gaining access to your machine, or a shared terminal environment could quickly discover any credentials you entered directly into the shell.
Fortunately, most applications offer secure methods for passing credentials without entering them in plaintext.
If you encounter an application requiring plaintext credentials, consider alternative approaches outlined in the next section. Most of the time, you can work safely without exposing credentials.
However, if you find a tool that offers no secure credential handling options, it’s advisable to consult your security team.
Similar to Bash history, logs can expose secrets stored in plaintext or loaded insecurely. Log files, found in /var/log, are potentially accessible to unintended parties, making them less secure than your Bash history.
While piping credentials between locations is generally secure, it becomes risky when calling the special /dev/stdin file. Shells like Bash automatically store any input from stdin (Standard Input) into a file that can be accessed by other processes on your machine.
If malware, spyware, or injected code exists on your computer or scripts, they can intercept plaintext contents from this file, even if you securely loaded a password or key into stdin from a trusted source.
The ps utility in Bash and related shells provides information about processes in memory.
It’s essential for understanding system activities. On UNIX-like operating systems, values, including the contents of private key files, can be seen via ps when these commands are running.
This information is stored locally in files like /proc/
This situation becomes especially risky on machines with shared access, such as remote VMs or servers.
Securing your secrets in these scenarios is critical to preventing unauthorized access and maintaining the integrity of your sensitive information.
Securing command line credentials need not be an intimidating endeavor; several approaches and tools can empower you to work more securely and confidently in your daily tasks.
While we’ll delve into some of these strategies here, we acknowledge that there may be additional tools and insights to address this challenge, and we welcome your contributions through social media or our contact form.
You may already be familiar with the password managers used in web browsers. Similarly, numerous tools are available to help you securely store and manage passwords for command line use.
HashiCorp Vault is an excellent example of such a solution. Vault’s documentation provides valuable guidance on leveraging it to programmatically access credentials without exposing them in plaintext.
When a potential threat actor gains access to your code, they will encounter calls to Vault rather than the actual keys, significantly raising the bar for any malicious intent.
These tools, similar to LastPass, 1Password, or DashLane for web interfaces, simplify password management for the command line, bolstering security and reducing the risk associated with storing sensitive credentials.
$ vault kv -help
Usage: vault kv <subcommand> [options]
Key-Value (KV) secrets engine commands. The KV secrets engine is used for storing, retrieving, and managing secrets.
Subcommands:
get Read the value of a key.
put Write a new key with a given value.
list List all keys in a given path.
delete Delete a key.
metadata Retrieve metadata about a key.
version Retrieve information about the version of the key.
There are several alternatives to HashiCorp Vault for securely managing passwords and sensitive data, such as KeePass, Azure Key Vault, Keeper Password Manager, and Akeyless Vault Platform, among others.
Each of these solutions has its own unique features and benefits, but the primary goal is to keep your passwords and sensitive information secure, preventing them from being stored in plaintext.
Your IT and security teams likely have approved password managers that you can start using immediately.
Encryption is a crucial aspect of data security, not only during data transmission but also when data is at rest.
Encrypting data at rest ensures that sensitive information remains protected when not actively in use. While managing encryption keys can add complexity, combining encryption with a robust password manager can make it relatively straightforward to keep credentials safe from malicious actors.
Here are three types of encryption tools that can be useful for enhancing data security:
Local filesystem encryption is designed to make it extremely difficult for unauthorized users to access your data if they gain physical or remote access to your computer.
When you’re not logged in, this type of encryption automatically secures the data on your machine, rendering it unusable to anyone without the proper credentials.
For Linux systems, many options are available, typically based on LUKS (Linux Unified Key Setup).
In fact, when installing most Linux distributions, you may be prompted to enable local filesystem encryption by default.
By implementing these encryption tools and a trusted password manager, you can significantly enhance the security of your data, ensuring that sensitive information remains protected from potential threats and unauthorized access.
For Windows users, there are several encryption tools available to enhance data security. Microsoft’s BitLocker, Folder Lock, and free open-source solutions like VeraCrypt are viable options.
These tools allow users to encrypt their data, providing an additional layer of protection against unauthorized access.
If you are using a newer MacBook with the T2 security chip integrated, you already have access to a robust encryption tool called FileVault. FileVault is designed to secure your data on macOS, ensuring that sensitive information remains protected.
Another useful tool for managing sensitive data is SOPS, which stands for “Secrets OPerationS.” SOPS is an encrypted file editor developed by the Mozilla team. Unlike local file encryption methods, SOPS streamlines the process of working with highly sensitive files.
Instead of manually decrypting files, editing them, and then re-encrypting, SOPS offers an editing experience that maintains encryption throughout the process.
When you open files encoded with SOPS in other text editing tools, the file’s structure remains intact, but any sensitive data is safeguarded.
In short, Windows users can choose from tools like BitLocker, Folder Lock, or VeraCrypt for encryption.
Mac users with T2 security chips can rely on FileVault for data protection.
Additionally, SOPS, developed by Mozilla, provides an efficient and secure way to edit encrypted files while keeping sensitive information safe throughout the editing process.
SOPS is highly customizable and allows you to choose from multiple encryption mechanisms like GPG or Hashicorp Vault, making it easy to fit your workflow.
It is a free and open-source tool. There is even a VS Code extension available. Shellclear is a cross-platform shell plugin that promises “a simple and fast way to secure your shell commands history”.
SOPS offers a high degree of customization, allowing users to select from various encryption mechanisms such as GPG or HashiCorp Vault.
This flexibility makes it easy to integrate SOPS into your existing workflow, and it’s important to note that SOPS is a free and open-source tool.
Additionally, there is a Visual Studio Code extension available, enhancing its usability within your development environment.
Shellclear, on the other hand, is a versatile cross-platform shell plugin designed to enhance the security of your command history. Its key features include:
Displaying sensitive command summary
When you open a new terminal session, Shellclear provides a clear summary of sensitive commands, helping you identify potentially confidential or security-sensitive operations.
Clearing sensitive commands
Shellclear automatically removes sensitive commands from your shell history, ensuring that they don’t linger in your command history, where they could potentially be accessed by unauthorized users.
History command stashing
For situations like presentations or screen sharing, Shellclear allows you to temporarily stash your command history.
This feature ensures that sensitive commands are hidden during these activities, reducing the risk of accidentally revealing confidential information.
In short, Shellclear is a valuable tool for securing your shell command history by providing command summaries, clearing sensitive commands from history, and allowing you to stash your command history temporarily for specific scenarios like presentations or screen sharing.
Shellclear is a free and open-source tool that offers high customizability.
While it’s a relatively new project, it provides an elegant solution for identifying and managing secrets present in your Bash history, aiding in their removal.
When it comes to securing data at rest on your machine, there are numerous tools and methods available.
When evaluating encryption tools, it’s essential to ensure they utilize proven and established encryption algorithms. This is an area where it’s crucial not to attempt to create your own encryption scheme.
Consult with your organization’s security experts to explore other approved options and tools that align with your security requirements.
In the simplest terms, environmental variables are settings used by the terminal to configure behaviors like time formatting or local UTF encoding. By default, these variables are accessible to the current user and the system during runtime.
Environmental variables can also serve to locally store credentials, especially for systems accessed programmatically.
This approach is generally considered secure because these credentials are stored within the system and can be easily invoked in scripts. However, it’s important to keep a few considerations in mind:
Ensure that environmental variables are scoped correctly, meaning they are not set at a global level. Scoping them properly restricts their access to only the necessary processes or users.
Be aware that when a process spawns a child subprocess, it copies its parent’s environmental variables to the child. This means that if a script has access to sensitive environmental variables, those variables will be passed to any other processes it launches. Careful management of sensitive environmental variables is crucial to prevent unintended exposure.
$ export MESSAGE="Test Message"
$ echo $MESSAGE
Test Message
In short, environmental variables are a useful means of storing credentials locally, especially for programmatic access.
However, it’s essential to set them with the appropriate scope and consider the inheritance of environmental variables when launching subprocesses to maintain security.
$ env | grep MESSAGE
MESSAGE=Test Message
If you’ve never run the ‘env’ command in a terminal, you might find the number of environmental variables already present overwhelming.
We invite you to open a terminal and run it now. If you happen to spot any variables that resemble API keys or bearer tokens, it’s a prudent idea to inquire whether they are still necessary and remove any environmental variables that are no longer in use to minimize potential security risks.
Pipes in Bash are a powerful and versatile feature that we generally love. They allow you to take the output from one process or application and pass it seamlessly into another.
Pipes are secure in themselves because they exist only in memory and have only two ends for the duration of the communication.
The potential security concern with pipes arises from the temporary storage of items in standard input, stdin.
This issue can be mitigated by moving the input to the pipe closer to the data source, which is the application feeding into stdin.
For instance, consider the example of using cURL.
Instead of passing data to a request by reading from stdin with -d “$(< /dev/stdin)”, cURL allows you to obtain the data directly from the source without writing to stdin using -d @-.
This approach enhances security by minimizing the exposure of sensitive data.
Working on the command line offers increased speed and efficiency, along with access to a wide range of tools.
However, as discussed in this article, it also introduces certain security concerns, particularly when it comes to managing credentials.
The good news is that you’re not alone in the effort to safeguard your secrets. Numerous tools are available to help you keep your credentials safe and secure.
Identify all the places where credentials are stored on your computer and accessed via the command line. These credentials can include passwords, keys, and certificates.
Stay vigilant and be aware of how your local credentials can potentially be compromised. Avoid storing sensitive information in plaintext or even referencing standard input as ‘/dev/stdin,’ as this is likely an insecure approach.
Utilize tools to keep files encrypted when they are at rest. Additionally, leverage tools that enable you to maintain the cleanliness of your logs and Bash history, reducing the risk of sensitive information exposure.
We encourage you to engage in discussions with your teams about security practices and inquire about tools that have already been vetted for your organization.
Collaborating with your security experts can help you identify ways to work securely on the command line while maintaining productivity.
