Home Cryptographic Recommendation Summary
Post
Cancel

Cryptographic Recommendation Summary

This post contains recommendation summaries for password security and cryptographic topics including password complexity & storage, hash functions, symmetric & asymmetric encryption, MACs, and TLS server configurations.

Each section contains a general summary of the common algorithms and recommendations, as well as links to the sources where these recommendations were obtained. Justification is not provided for these recommendations, as it can be found in the links provided.

  1. Password Complexity
  2. Password Storage
  3. Hash Functions
  4. Symmetric Encryption
  5. Asymmetric Encryption
  6. Message Authentication Codes (MACs)
  7. TLS Configuration

Password Complexity

  1. Password length is more important than complexity. 8 characters shall be the minimum length acceptable, but ideally longer (10-12+). The minimum length should take into consideration the threat model being address and the confidentiality of the system and data being protected.

  2. Password length limit should be enforced to prevent excessive processing time, but not so small that strong lengthy passwords are discouraged. Allow at least 64 characters.

  3. No periodic password rotation. Passwords shall only be force changed if there is evidence of compromise.

  4. Don’t allow password hints.

  5. Allow pasting in the password field. This allows users to copy and paste from password managers.

Password systems should check the supplied password against the following:

  • Passwords from public breaches
  • Dictionary words
  • Repetitive & sequential characters/numbers (e.g. abcdef, 12345, 111111)
  • Inclusion of username, userId, business name, application name


NIST - Special Publication: Authentication and Lifecycle Management



Password Storage

  1. Always hash, never encrypt.
  2. Hash the password using HMAC with an approved hash algorithm (SHA-2 or SHA-3 family) with a shared value (called a pepper) as the key. This key shall not be stored in the database, but instead on disk or in key store. This ensures that access/compromise of the database alone will not be enough to trivially recover passwords.
  3. Base64 encode the output hash to avoid null bytes being used as the input to the next step.
  4. Use a slow hash algorithm such as bcrypt, Argon2, or PBKDF2 to calculate the hash of the base64 encoded string with a different cryptographically random salt being used for each user. Note, the work factor should be tuned to an appropriate level for the application.
  5. The resulting hash and salt should be stored in the database.


NIST - Special Publication: Authentication and Lifecycle Management

Mozilla Web Development - Let’s talk about password storage

OWASP - Password Storage Cheat Sheet



Hash Functions

MD2, MD4, MD5 & SHA-1 shall NOT be used except for where backwards compatibility is required. No new applications shall utilise these algorithms.

SHA-2 is safe to use for applications that require secure hash algorithms. The four fixed length SHA-3 algorithms SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, & SHA-512/256 are all approved for use.

SHA-3 is safe to use for applications that require secure hash algorithms. The four fixed length SHA-3 algorithms SHA3-224, SHA3-256, SHA3-384, & SHA3-512 are all approved for use.


NIST - NIST Policy on Hash Functions

NIST - Transitioning the Use of Cryptographic Algorithms and Key Lengths

Microsoft Cryptography - Hash and Signature Algorithms



Symmetric Encryption

Block Ciphers

RC2, RC4, Blowfish, Skipjack, DES, 3DES/TDEA shall ONLY be used for legacy decryption. These algorithms are disallowed for encryption purposes. No new applications shall utilise these algorithms.

  • Note: Three-key TDEA for encryption is deprecated through 2023, and will be disallowed after 2023.

AES (Advanced Encryption Standard) is recommended for all block cipher encryption needs. The use of AES-128, AES-192, & AES-256 is acceptable for encryption and decryption. AES is a FIPS-approved symmetric-key algorithm that may be used by to protect sensitive information.


NIST - Transitioning the Use of Cryptographic Algorithms and Key Lengths

OWASP - Testing for Weak Encryption

Microsoft Cryptography - Microsoft SDL Cryptographic Recommendations


Cipher Modes

ECB, CBC, OFB, CFB, CTR shall NOT be used as they provided confidentiality only, but not authenticated encryption. ECB shall NOT be used under any circumstance.

CCM, GCM shall be used as they provide both confidentiality and authentication.

  • Other FIPS certified block cipher modes do exist. However, they have limited and often very specific use cases.

IVs (Initialization Vectors) and Salts used must be unique and cryptographically strong random numbers. IVs should never be reused, especially in CTR and GCM cipher modes.


NIST - Block Cipher Techniques

NIST - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality

NIST - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC


Key Derivation

PBKDF1 (Password-Based Key Derivation Function 1) shall NOT be used as it has a maximum key length of 160 bits.

PBKDF2 (Password-Based Key Derivation Function 2) should be used when a user supplied key is required as input. The provided salt shall be at least 32 bits long and cryptographically random. The iteration count should be as high as possible whilst not negatively impacting server performance. An iteration count of a minimum of 10,000 shall be used.


NIST - Special Publication: Authentication and Lifecycle Management

IETF - PKCS #5: Password-Based Cryptography Specification Version 2.0



Asymmetric Encryption

Digital Signatures

DSA with private key that provide less than 112 bits of security shall NOT be used for digital signature generation.

DSA with private key that provide at least 112 bits of security shall be used for digital signature generation.

  • DSA domain parameters should be (2048, 224) or (2048, 256) shall be used for 112 bits of security, or (3072, 256) shall be used which provides 128 bits of security.

RSA with len(n) < 2048 bits shall NOT be used for digital signature generation

RSA with len(n) >= 2048 bits shall be used for digital signature generation. Any modulus with an even bit length that provides at least 112 bits of security strength may be used.

RSA Modulus length (n) in bitsBit of Security
2048112
3072128
4096152
6144176
8192200

ECDSA: with len(n) < 224 bits shall NOT be used for digital signature generation.

ECDSA: with len(n) >= 224 bits shall be used for digital signature generation.


NIST - Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography

NIST - Transitioning the Use of Cryptographic Algorithms and Key Lengths



Message Authentication Codes (MACs)

Key lengths < 112 bits shall NOT be used for HMAC Generation as they are disallowed.

Key lengths >= 112 bits shall be used for HMAC Generation.


NIST - Transitioning the Use of Cryptographic Algorithms and Key Lengths



TLS Configuration

SSL/TLS Versions

SSLv2 & SSLv3 shall be DISABLED and not be used. This may potentially cause compatibility issues if Windows XP SP2 and older systems require support.

TLSv1.0 & TLSv1.1 shall be DISABLED unless there is a strong requirement for backwards compatibility.

TLSv1.2 & TLSv1.3 shall be the only two version used. TLSv1.3 shall be supported by all government and citizen applications by January 1st 2024. TLSv1.2 should be disabled if it is not needed for interoperability.


Mozilla Wiki - Security/Server Side TLS

Microsoft Cryptography - Microsoft SDL Cryptographic Recommendations

IETF - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)


Cipher Suites

Null cipher shall be DISABLED and never used.

MD5, SHA1, RC4, DES, 3DES/TDEA cipher suites shall be DISABLED as they are no longer considered secure.


NIST - Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

Mozilla Wiki - Security/Server Side TLS

OWASP - Testing for Weak Transport Layer Security


Configuration Options

TLS SCSV (Fallback Signaling Cipher Suite Value) shall be supported for TLSv1.0, v1.1, & v1.2. This is not required for TLSv1.3 as it includes a mechanism to protect against this downgrade attack.

TLS Compression shall NOT be utilised and all methods shall be disabled.

TLS SNI (Server Name Indication) shall be supported by all versions of TLS. The server shall be able to support multiple virtual servers that may exist at the same network address.

HSTS (HTTPS Strict Transport Security) shall be configured with max-age=63072000 (two years).

Certificate Lifespan shall be 90 days, and shall NOT more than 366 days.


Mozilla Wiki - Security/Server Side TLS

NIST - Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations



This post is licensed under CC BY 4.0 by the author.