Safeguarding Sensitive Credentials

Abstract

It is essential for application developers to safeguard their sensitive credentials. Hardcoding sensitive credentials is one of the most common mistakes developers make when developing an application. Hardcoding sensitive credentials, such as API keys and secret keys, can lead to exposure of these credentials. This technical paper explains the risks of hardcoding sensitive data and outlines steps you can take to avoid them.

Introduction

This technical paper advises you, as a developer, on how to avoid hardcoding credentials as a shortcut to save time on launch or release of new features, and as a result, avoid incurring a security gap. This document provides guidance on best practices such as layer protection, rotation of encryption keys, and the use of private code repositories instead of public ones.

Data Protection Policy (DPP) requirements

One of the policies which you agreed to when starting the process of developing a service for the Selling Partner Appstore is the Amazon Seller Central Data Protection Policy. In the Secure Coding Practices section, the DPP states:

Developers must not hardcode sensitive credentials in their code, including encryption keys, secret access keys, or passwords. Sensitive credentials must not be exposed in public code repositories. Developers must maintain separate test and production environments.

Software development processes

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 technical paper to represent passwords, personal identification numbers (PINs), secure shell (SSH) 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-O2T16:46:23Z",
    "AccessKeyId":"ASIAXQZXUENECYQBAAQG"
  }
}

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, because it is difficult to discern whether access is legitimate or illegitimate.

Rather than hardcoding credentials, developers should 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 applications

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

Developers must protect these credentials accordingly, as the risks and mitigating actions described in this technical paper apply to them.

Amazon's 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 developers don’t realize Amazon has rotated their keys and they spend valuable time researching the root cause of their interruption. It can take days for a developer 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 became 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 developer’s awareness.

The best way to avoid such stressful interruptions to your business is to avoid hardcoding your credentials.

Best practices for handling credentials

The following sections discuss best practices for handling credentials.

Layer protection

Credentials must be protected in a secure credential store. A credential store helps users protect secrets needed to access applications, services, and IT resources. Using a credential store allows users 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.

Because 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. You’ll also want to encrypt the contents with strong encryption algorithms and robust logging, monitoring, alerting that will enable rapid incident response.

Key rotation

A best practice is to assume that your credentials will be exposed eventually. Mitigate this assumed risk by establishing a key 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. Amazon recommends automatically rotating keys at least every 180 days.

Maintaining 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 technical paper, you also ensure that your repositories remain private.

You can help further protect credentials and sensitive assets by maintaining private code repositories. A private repository will not fully protect your credentials and is not a substitute for implementing the recommendations in this technical paper.

If you are a developer 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 developers with an on-premise environment can also leverage equivalent services to achieve the same goal.

Developers can take advantage of AWS IAM roles to reduce authentication and control process efforts. However, some services and applications require longer lived credentials, in cases such as API keys, password databases, and SSH keys, which shouldn’t 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, developers can set up Secrets Manager for users and services to retrieve credentials via 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.

Conclusion

By following the best practices outlined in this technical paper, such as layer protection, rotation of encryption keys, and the use of private code repositories instead of public ones, you can help ensure that your data and applications are safe. Do not sacrifice security over speed, as it is beneficial to have a robust software development lifecycle that integrates security as a top priority to ensure that a secure product is launched on time.

Further reading

For additional information, refer to:

• Data Protection Policy
• Acceptable Use Policy
• 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

Document history

Notices

Amazon sellers and developers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current practices, which are subject to change without notice, and (c) does not create any commitments or assurances from Amazon.com Services LLC (Amazon) and its affiliates, suppliers or licensors. Amazon Services API products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of Amazon regarding Amazon Services API are controlled by Amazon Services API agreements (including the Amazon Services API Developer Agreement or the Amazon Services Business Solutions Agreement), and this document is not part of, nor does it modify, any agreement between Amazon and any party.

© 2023 Amazon.com Services LLC or its affiliates. All rights reserved.