OWASP Top 10 Cryptographic Failures

The Open Web Application Security Project (OWASP) cites lapses in cryptography practices in its Top 10 2021 Cryptographic Failures, focusing on data that falls under privacy laws, including the EU's General Data Protection Regulation (GDPR), and regulations for financial data protection, such as PCI Data Security Standard (PCI DSS).  

The OWASP document describes failures related to cryptography, noting Common Weakness Enumerations (CWEs)—a community-developed list of software and hardware weakness types—such as CWE-259, the Use of Hard-coded Password, the CWE-327, Broken or Risky Crypto Algorithm and CWE-331 Insufficient Entropy. 

“The first thing is to determine the protection needs of data in transit and at rest,” the document says, citing passwords, credit card numbers, health records, personal information, and business secrets that under privacy laws or regulations such as GDPR and PCI DSS.  

What this level of evaluation highlights is the importance of gathering intelligence about the health of your machine identities. It goes without saying that your machine identity management program is only as good as your weakest certificate. OWASP lists the types of vulnerabilities that you should be looking for—some of them are simply best practice checks and others require in-depth intelligence at a certificate level.  

OWASP cites the following concerns:  

• Data transmitted in clear text using protocols such as HTTP, SMTP, FTP also using TLS upgrades like STARTTLS. “External internet traffic is hazardous. Verify all internal traffic, e.g., between load balancers, web servers, or back-end systems.” 

• Old or weak cryptographic algorithms or protocols used either by default or in older code. 

• Default crypto keys and weak crypto keys generated or re-used. Missing proper key management or rotation. Crypto keys not checked into source code repositories.  

• Properly enforced encryption. Are any HTTP headers (browser) security directives or headers missing? 

• Proper validation of the received server certificate and the trust chain. 

• Initialization vectors that are ignored, reused, or may not be sufficiently secure for the cryptographic mode of operation. Is an insecure mode of operation such as ECB in use? Is encryption used when authenticated encryption is more appropriate? 

• Passwords being used as cryptographic keys in absence of a password base key derivation function. 

• Randomness used for cryptographic purposes that was not designed to meet cryptographic requirements. 

• Deprecated hash functions such as MD5 or SHA1. 

• Deprecated cryptographic padding methods such as PKCS number 1 v1.5. 

This is what you should be looking for to avoid being exposed to machine identity compromises. And many organizations can proactively address these problems through policies. But it’s always the outlier that will cause problems down the road. And to make your job even more difficult, those problems are most often not on your radar. Often, they are a result of a rogue department using unauthorized Certificate Authorities (CAs). Or they simply weren’t properly tracked in the first place.  

OWASP enumerates the following prevention measures:  

• Data that is not retained cannot be stolen. Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation.  

• Make sure to encrypt all sensitive data at rest. 

• Make sure strong standard algorithms, protocols, and keys are in place and use proper key management. 

• Encrypt all data in transit with secure protocols such as TLS with forward secrecy (FS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS). 

• Disable caching for response that contain sensitive data. 

• Do not use legacy protocols such as FTP and SMTP for transporting sensitive data. 

• Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2. 

• Initialization vectors must be chosen appropriate for the mode of operation. For many modes, this means using a CSPRNG (cryptographically secure pseudo random number generator). For modes that require a nonce, then the initialization vector does not need a CSPRNG. In all cases, the initialization vector should never be used twice for a fixed key. 

• Always use authenticated encryption instead of just encryption. 

• Keys should be generated cryptographically randomly and stored in memory as byte arrays. If a password is used, then it must be converted to a key via an appropriate password base key derivation function. 

• Ensure that cryptographic randomness is used where appropriate, and that it has not been seeded in a predictable way or with low entropy. Most modern APIs do not require the developer to seed the CSPRNG to get security. 

• Avoid deprecated cryptographic functions and padding schemes, such as MD5, SHA1, PKCS number 1 v1.5 . 

• Verify independently the effectiveness of configuration and settings. 

To find the worst offenders, you’ll need a way to automate discovery of all machine identities across your network. And you’ll need the resulting certificate intelligence to contain abundant data that will help you identify and remediate potential vulnerabilities. A robust platform for machine identity management is certainly the most comprehensive (and efficient) vehicle for gathering the actionable data you need to keep your machine identities safe. 

Related Posts

• Code Signing Certificates [Your In-Depth Guide] 

• Venafi CodeSign Protect 

• Certificate Management for Code Signing 

• CISO’s and CIOs: Are you aware of the lurking time bombs?