B.10 - Data Security
B.10.1 General
Only standard and mature cryptographic algorithms, operation modes, key lengths ciphers, and implementations MUST be used.
B.10.2 Encryption at Transit
- All external communication MUST only be possible via TLS/HTTPS.
- In cases where access requires HTTPS, requests via HTTP MUST be redirected to HTTPS. This SHOULD be implemented with a permanent redirection (HTTP 301).
- HTTPS servers MUST only support current secure ciphers and protocols. Insecure or deprecated ones (e.g. SSLv2, TLSv1.0, TLSv1.1 and RC4 cipher) MUST be deactivated 1.
- External Websites MUST receive at least an “A” rating from the SSL Labs Server Test2. Internal Websites SHOULD use another test tool to verify their settings.
- Confidential data MUST only be sent within the HTTP request body (e.g. via HTTP POST) or header but not within URLs.
- Transmission on untrusted channels (e.g. the Internet) MUST
B.10.2 X.509 Certificates
- External HTTPS connections MUST use valid X.509 certificates issued by a trusted certificate authority (CA).
- X.509 certificates MUST use RSA with at least 3072 bit or ECDSA with at least 256 bit keys3.
- External customer applications (UIs) SHOULD use Extended Validation (EV) certificates.
- Wildcard certificated MUST not be used.
B.10.3 Encryption at Rest
- Confidential data MUST be encrypted before being stored.
- Access to encryption keys MUST be handled according to the requirements specified in B.11 - Protection of Secrets
- Only secure algorithms MUST be used for encryption4.
- User passwords MUST be persisted according to requirements at B.6 - User Passwords.
B.10.4 Cryptographic Integrity Checks
- Security-sensitive integrity validation MUST be performed using either cryptographic hash functions (e.g. sha256 or hmac-sha256)5 or using public key cryptography36.
- Integrity validation within a distributed architecture (aka “data authentication”) SHOULD utilize public key cryptography rather than HMACs, particularly when a secret key would otherwise be shared among multiple systems.
B.10.5 Tokens / Keys
- Tokens (or keys) that are used for security purposes (e.g. access tokens, passwords of technical users, or API keys) MUST be cryptographically random and at least 256-bit (= 32 characters) length 7.
- Non-opaque tokens MUST be signed using preferably public key cryptography or cryptographic hash functions (see above).
-
See SSL Best Practices by SSL.com or OWASP TLS Cheat Sheet for details. ↩
-
See SSL Test by Qualys ↩
-
See NIST 800-131A,R2, Chap 2, Table 2, pg. 9 ↩ ↩2
-
See NIST 800-131A,R2, Chap 1, Table 1, pg. 7 ↩
-
See NIST 800-131A,R2, Chap 9, Table 9, pg. 18 ↩
-
You can use JOSE(Javascript Object Signing and Encryption) for signing JSON objects or XML Signature for XML objects. ↩
-
To archive this you may use an UUID or generate one directly using the OpenSSL CLI. Here is an example for creating a 256bit token encoded as Base64
$ openssl rand -base64 32
↩