Safeguarding Sensitive Credentials for SP-API Applications

Abstract

Ensuring that sensitive credentials are safeguarded is fundamental for application developers. 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 whitepaper explains the risks of hardcoding sensitive data and outlines steps you can take to avoid them.

Introduction

This Whitepaper advises developers 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

As stated in the Amazon Seller Central Data Protection Policy under Secure Coding Practices,

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 may feel the need 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 whitepaper to represent passwords, personal identification numbers (PINs), secure shell (SSH) keys, encryption and decryption keys, and Amazon SP-API secret access keys 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 may seem attractive in 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 may 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, 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

Developers with Selling Partner API (SP-API) applications have a different set of credentials to take into account. Since SP-API relies on AWS Identity and Access Management (IAM), the AWS IAM role or IAM user used to create your application must be protected as well. SP-API also 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 whitepaper apply to them.

Amazon's protections

Amazon continually scans the internet to detect if sensitive credentials like Amazon SP-API secret access keys 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 utilize 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. 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 whitepaper, you also ensure that your repositories remain private.

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

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 is guidance crafted by Nathan Case, an AWS Security Strategist, who advises AWS customers on protecting their credentials.

When you build applications on AWS, you can use AWS IAM roles to deliver temporary lived credentials for calling AWS services. However, some applications require longer lived credentials, such as database passwords or other API keys. If this is the case, you should never hard code these secrets in the application or store them in source code.

You can use AWS Secrets Manager to control the information in your application. Secrets Manager allows you to rotate, manage, and retrieve database credentials, API keys, and other secrets through their lifecycle. Users and applications can retrieve secrets with a call to Secrets Manager APIs, eliminating the need to hard code sensitive information in plain text.

You should also learn how to use AWS IAM roles for applications running on Amazon EC2. Also, for best results, learn how to securely provide database credentials to AWS Lambda functions by using AWS Secrets Manager.

While this information is tailored to issues AWS customers face, other cloud provider customers or developers with an on-premise environment can also leverage equivalent services to achieve the same goal.

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.

Conclusion

By following the best practices outlined in this whitepaper, 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 life cycle that integrates security as a top priority to ensure that a secure product is launched on time.

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. This document is not part of, nor does it modify, any agreement between Amazon and any party.