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.
- Password Complexity
- Password Storage
- Hash Functions
- Symmetric Encryption
- Asymmetric Encryption
- Message Authentication Codes (MACs)
- TLS Configuration
Password Complexity
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.
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.
No periodic password rotation. Passwords shall only be force changed if there is evidence of compromise.
Don’t allow password hints.
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
- Always hash, never encrypt.
- 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 a key store. This ensures that access/compromise of the database alone will not be enough to trivially recover passwords.
- Base64 encode the output hash to avoid null bytes being used as the input to the next step.
- 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. The work factor (slowness) should be tuned to an appropriate level for the application.
- 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: 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 bits | Bit of Security |
|---|---|
| 2048 | 112 |
| 3072 | 128 |
| 4096 | 152 |
| 6144 | 176 |
| 8192 | 200 |
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
Tools for Checking TLS/SSL 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
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.
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