Learn strategies for safeguarding application, database, and server credentials.
- Credentials are usernames and passwords. Website code often uses credentials to connect to databases, to connect to a payment processor, to access third-party APIs, or to connect to source code repositories. These credentials are valuable access keys that need to be handled securely. Don't put credentials directly inside your code. We call this hard-coding the credentials. Instead, store the credentials in a separate file, and use variables or even better constants to refer to the values. Separating configuration from the code is considered a best practice. It's also more secure. These values are still in the project, but it's easier to give special treatment to a separate credentials file. Version control systems, such as Git, SVN, and Mercurial, present unique challenges for credentials. These code management tools are often used to distribute code via shared repositories on third party services. Adding credentials to version control is like shouting a secret on a busy street. Your project collaborators will be able to see the credentials. Your collaborators may be trustworthy, but they could be hacked or lose their laptop. The third party hosting company can see the credentials too. You're going to be trusting them not to peek or make any mistakes which might expose your information. In addition, version control systems are designed to track data over time in a way that's really hard to forge or circumvent, it's difficult to purge a file from the history once it's been added to version control. All files with credentials should be excluded from version control right from the start of a project. This prevents your credentials from being shared. If you've already committed credentials to version control, you should exclude the file and then use different credentials. Some developers even use the environment variables of the operating system to store credentials as a way to ensure that they cannot be checked in accidentally. Excluding files from version control also encourages collaborators to create their own file with unique credentials instead of sharing a set of common ones. You should never reuse passwords. Passwords should be unique for every computer, every environment, and every database. If credentials are exposed or stolen, the access granted by each password will be limited. Another common concern is how to store credentials. A server which must be able to use credentials without a human around to provide them must have those credentials stored somewhere on the server. Developers often struggle with this. They know that user passwords in a database should be hashed and never stored in plain text. So it seems insecure to use plain text for passwords that connect to databases or other services. In most cases, it is acceptable to store access credentials to other servers in plain text. Some developers use obfuscation techniques to hide credentials, but in my opinion, it adds little security. The obfuscation is easily removed, especially by anyone with enough access to the server to see those credentials in the first place. The credentials could be encrypted, which provides strong protection, but then the key or password to decrypt them must also be present on the server. It's a chicken and egg problem. If the server can decrypt a password, then so can someone with access to that server. Another area where credentials are important is when developers use them to connect to remote servers. For example, using FTP or SSH. A username and a password are acceptable, but SSH keys are a more convenient and secure option. SSH keys use public key cryptography to create two files which are mathematically linked together. They're known as a key pair, with one public key which can be shared, and one private key which is kept secret. You can put the public key on remote servers and on code repositories like GitHub. When you access those servers, the public key and your private key interact to authenticate you and to grant access. It's more secure than a username and password, because that private key acts like a really long password, over 1,000 characters long, which is almost impossible to guess. It's more convenient because you don't have to type any password to log in. The SSH key will be sent automatically. For even stronger security, you can require SSH keys for all users and disable password logins completely. This removes any chance that an attacker could guess a user's password. Credentials are keys to areas we work hard to keep secure. It's essential that we secure those keys too. Do not let poor handling of credentials become a weak link in your security.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting