non-starter. As a result, application teams sometimes make the mistake of
storing key material in unsecured locations, such as in code, in client-side
storage, or in general purpose cloud storage, all of which are frequently
harvested by attackers.
2.
Transport protection should suffice for most business and security
cases:
most organizations have a hard enough time implementing TLS.
Encrypting message bodies or payloads on top of encrypted transport can
be overkill. This added layer of encryption requires a high level of effort to
do effectively, not to mention that it can also add latency or can create
integration headaches with other systems. More often than not, attackers
defeat such mechanisms by harvesting exchanged key material that the
client needs in order to encrypt and decrypt data from back-end APIs.
3.
Always use well-vetted algorithms and encryption libraries:
many
implementation details of encryption are important to get “right” to avoid
incidents such as salt sizes, rounds of salting, initialization vectors, key
sizes, and more. These considerations also vary for symmetric encryption
and asymmetric encryption. NIST provides some guidance on encryption,
but you will also need to augment with specifics related to your technology
stack. Guidance evolves over time as new encryption exploits surface or
weaknesses are uncovered in cipher suites. You must also properly maintain
encryption tooling and code libraries since flaws can be uncovered over
time, such as OpenSSL and the Heartbleed bug. This best practice is not
just a developer problem since encryption tooling and libraries are used in
many layers of the technology stack.
4.
Dostları ilə paylaş: 
