Safeguarding Sensitive Credentials

Protecting sensitive credentials is critical for application security. In the rush to launch a new product, organizations might want to take shortcuts, including hardcoding sensitive credentials. Hardcoding is the act of saving credentials outside of a secure credential store, and includes source code, wikis, documentation, spreadsheets, and configuration files. Credentials is the term used in this guide to represent passwords, personal identification numbers (PINs), secure shell (SSH) keys, API keys, encryption and decryption keys, and Amazon SP-API client credentials or tokens.

The following is an example of hardcoded credentials:

{ "AssumedRoleUser":
  {
    "AssumedRoleId": "AROAIEGLQIIQUSJ2I5XRM:s3-access",
    "Arn": "arn:aws:sts:AWS-ACCOUNT-NUMBER:assumed-role/s3-read/s3-access"
  },
  "Credentials": {
    "SecretAccessKey":"wZJph6PX3snOZU4g6yfXdkyXp5m+nwkEtdUHwC3w",
    "SessionToken": "FQoGZXIvYXdzENr/////////<<REST-OF-TOKEN>>",
    "Expiration":"2018-11-02T16:46:23Z",
    "AccessKeyId":"ASIAXQZXUENECYQBAAQG"
  }
}

Solution providers who hardcode credentials create a leading cause of security breaches. Hardcoded credentials expose themselves to attackers through code repositories, documentation, or configuration files.

This guide establishes mandatory security practices for sensitive credentials. To eliminate credential exposure risks, solution providers must implement secure credential storage through encrypted credential stores, automate annual key rotation, and maintain private code repositories with robust access controls and monitoring systems.

Amazon Data Protection Policy (DPP) requirements

To comply with the Secure Coding Practices requirements in the DPP, solution providers must:

• Ensure that sensitive credentials, including encryption keys, secret access keys, or passwords, are not hardcoded in their code.
• Ensure that sensitive credentials are not exposed in public code repositories.
• Maintain separate test and production environments.

Credential hardcoding risks

While hardcoding credentials can seem like an option for the development process, it creates significant risks in your applications. If a malicious actor can gain access to your codebase, they can easily gain access to the credentials. The malicious actor can then control any resource the credentials are authorized to access.

For example, if a malicious actor finds your Amazon SP-API credentials, they can make API calls on your behalf without your permission or knowledge. It is possible that you might never know whether an attacker is using your credentials, since it is difficult to discern whether access is legitimate or illegitimate.

Rather than hardcoding credentials, solution providers must store credentials in a secure credential store, such as AWS Secrets Manager. Your application can then call the credential store to retrieve necessary credentials only when needed.

Selling Partner API application credentials

For solution providers with Selling Partner API (SP-API) applications, SP-API relies on Login with Amazon (LWA) authorization codes, access tokens, and refresh tokens.

Solution providers must protect these credentials according to the requirements in the DPP.

Amazon's credential protections

Amazon continually scans the internet to detect if sensitive credentials are publicly available. When Amazon finds keys on the internet, the Information Security team rotates the keys to remove the risk and block malicious actors from taking control of the application. Amazon then informs the key owner.

Since the keys have been made publicly available, Amazon assumes that an unauthorized party has access to the keys, putting the Amazon SP-API application owners at risk. Unfortunately, rotating the keys means that the application owner cannot control the application, either.

While this process helps protect Amazon SP-API applications, it causes significant interruption for application owners and their customers. Typically, Amazon SP-API solution providers don’t realize that Amazon has rotated their keys and they spend valuable time researching the root cause of their interruption. It can take days for a solution provider to realize that Amazon rotated the keys and contact Amazon via a support case.

This is the only mechanism that Amazon has to protect your credentials. If another credential such as a decryption key were to become public, Amazon would not be able to disable or rotate the key. An attacker would have the authority to decrypt your sensitive information, without Amazon’s or your solution provider’s awareness.

To prevent service disruptions and security incidents, avoid hardcoding your credentials.

Best practices for handling credentials

The following sections discuss best practices for handling credentials.

Layer protection

Solution providers must protect credentials in a secure credential store. A credential store protects the secrets that are needed to access applications, services, and IT resources. Using a credential store allows you to have a single repository of all secrets, allowing for easier management to protect, rotate, manage, and use secrets across applications, services, and other protected resources.

Since a single credential store might store all of your secrets, it is imperative that the credential store is protected. To protect your credential store:

• Limit access to only the people and resources that require access.
• Require Multi-Factor Authentication (MFA) for all user accounts.
• Encrypt the contents with strong encryption algorithms.
• Establish robust logging, monitoring, and alerting systems that enable rapid incident response.
• Implement a Key Management System (KMS) that covers the complete key lifecycle management.

Control user access and passwords

Controlling user access is essential for preventing unauthorized credential exposure in any system. Solution providers must implement strict protocols around login credentials, avoiding the creation or use of generic, shared, or default accounts while preventing credential sharing between users. This starts with establishing a formal user access registration process that carefully assigns appropriate access rights for all user types and services, ensuring each person with computer access receives a unique ID.

Access management requires ongoing vigilance. To ensure that only required users can access information at any given time, solution providers must:

• Prevent employees and contractors from storing information on personal devices, as this creates uncontrolled access points that could bypass established security measures.
• Encrypt Amazon-provided API keys and limit their access strictly to required employees.
• Review access lists for both people and services every quarter.
• Disable employee access within 24 hours when they depart.

Account security is further strengthened through automated protection mechanisms. Solution providers must:

• Implement account lockout systems that can detect unusual usage patterns and login attempts.
• Automate account locking after 10 or fewer unsuccessful login attempts to prevent brute force attacks.
• Prevent the reuse of the last 10 passwords, ensuring users cannot revert to potentially compromised credentials.

Solution providers must ensure that passwords:

• Have a minimum length of 12 characters.
• Do not include any part of the user’s name, including first name, last name, username, or email address.
• Include a mix of upper-case letters, lower-case letters, numbers, special characters, including minimum requirements for each character.
• Have a minimum age of one day.
• Expire after a maximum of 365 days.

Schedule and automate key rotation

A best practice is to assume that your credentials will be exposed eventually. Solution providers must mitigate this risk by establishing a credential rotation schedule. Scheduling key rotation reduces the window of time that a compromised credential can be used by unauthorized users.

Key rotation is usually prompted by specific actions, such as the key holder relinquishing their need-to-know role, or the length of time that a key has been in service. For best practices, solution providers must automatically rotate API keys and associated credentials every year.

Maintain private code repositories

A public repository exposes your code to the world, making it available to competitors and attackers alike. This presents a significant risk of exposing your company’s normal operations. For this reason, Amazon recommends that in addition to following the recommendations in this guide, you also ensure that your repositories remain private.

Solution providers must implement additional measures to protect credentials and sensitive assets. Ensure that the credentials are not exposed in the repositories.

If you are a solution provider who uses GitHub as a primary code repository hosting service, you should refer to Setting repository visibility in GitHub’s documentation to learn how to make your repositories private. You should also consider leveraging built-in features from these services including automatic code scanning to detect credentials and encrypting secrets natively.

Guidance for Amazon Web Services (AWS) Customers

The following guidance is tailored to issues AWS customers face, however, other cloud provider customers and solution providers with an on-premise environment can also leverage equivalent services to achieve the same goal.

Solution providers can take advantage of AWS IAM roles to reduce authentication and control process efforts. However, some services and applications require credentials with extended validity periods, in cases such as API keys, password databases, and SSH keys, which should not be hardcoded into application source code.

AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, API keys, and other secrets throughout their lifecycles. Refer to the AWS Secrets Manager documentation for a basic scenario for using AWS Secrets Manager, tutorials, and guides. To avoid hardcoding credentials, solution providers can set up Secrets Manager for users and services to retrieve credentials using Secrets Manager API calls.

To increase effectiveness, it is recommended that you learn how to use AWS IAM roles for applications running on EC2. You should also learn how to securely provide credentials to AWS Lambda functions with Secrets Manager.

Key takeaways and next steps

• Eliminate hardcoded credentials immediately by auditing all source code, documentation, and configuration files and remove embedded API keys, passwords, and secret keys that create security vulnerabilities.
• Deploy secure credential infrastructure, including encrypted credential stores, complete KMS lifecycle management, and restricted API key access.
• Implement mandatory access controls with formal user registration processes, MFA for all accounts, account lockout after 10 failed attempts, and password history preventing reuse of last 10 passwords.
• Establish automated security maintenance, including annual API key rotation, quarterly access reviews, and 24-hour access removal for terminated employees.
• Consult the latest version of the Data Protection Policy and Acceptable Use Policy for the most up-to-date compliance requirements.

For additional information, refer to:

• Best Practices for Security, Identity & Compliance
• Setting repository visibility
• Store, Distribute, and Rotate Credentials Securely
• Top 10 security items to improve in your AWS account