Secure Secrets: Managing Authentication Credentials Threat Researcher Sr. Security Researcher

High level of trust

Finally, even if the secrets are stored in encrypted form, organizations would still have to achieve and maintain a certain level of trust and shared responsibility among their personnel. This is because certain individuals would still have to know or hold the decryption key.

Organizations should never forget that secrets must only be accessible to a select few. This translates to keeping read permission only for users or applications with a proper reason to access this storage or systems. Encrypting the secrets would then add additional security, with malicious actors having to work much harder to crack the credentials.

Secret transport

Aside from stored secrets, security would also be necessary for services that have to be configured and require transfer. It is important to emphasize that moving secrets is normal and therefore should be accounted for and done through a secure (i.e., encrypted) channel.

A secure channel means using a protocol that is secure by default, examples of such protocols are SSH or HTTPS. Using plain text-based protocols such as HTTP, SMTP, FTP to transfer secrets can allow malicious actors to intercept the communication and leverage the leaked secret.

It should be mentioned that putting secrets into a source code management (SCM) system is also not a good idea as it gives access to more people than necessary. Cases involving public repositories adds another layer of danger to SCM. Should an organization insist on using SCM, they should use tools that will encrypt the secret, (e.g., git-secret) to protect against the possibility of having the SCM used as an entry point in a supply chain attack, as we have discussed in a previous article.

Impact of secrets

This section looks into the implications of using unsecure secret storage in the context of today’s developing technologies, namely that of DevOps and the cloud. We also briefly describe a real-world scenario in which a threat actor goes after credentials in infected devices.

Secrets and DevOps

Today, most have gotten used to considering development and “local” environments as inherently secure. This is reflected by practices such as storing secrets in their unencrypted form, designing software to run in secure environments only, and not hardening security features by default. This provides additional comfort for users as it removes the need for a complex security configuration. The trade-off, however, is how these practices increase the risk of incurring a security incident. We have already seen the repercussions of supply chain attacks, weak VPN security, VPN vulnerabilities, etc.

It is also important to note that “local” environments are not that local anymore, as we are seeing more companies moving into the cloud. A plaintext secret that has been stored on a device that uses hardware-based (HW) encryption is simultaneously stored on a device connected to the cloud. In short, it is not secure to store a secret in plaintext whether in the cloud or not.

To give a real example from the world of DevOps, Visual Studio Code has only recently been able to provide support for secret storage in its release of  version 1.5353, released in January 2021. Before this update, no official API was available for storing secrets in a more secure manner and, thus, it was the developers’ responsibility to implement it securely.

Read More HERE