Common cryptographic vulnerabilities
Cryptography is often used in the most sensitive places, such as authentication, protection of secrets and communication. Despite its importance, cryptography often goes wrong, and when it goes wrong the impact is severe. According to OWASP, it is currently on the second place of the most critical web security risks [1].
This blog post describes three of the most common cryptographic failures and what can be done to avoid them.
Hardcoded secrets
Secrets, such as database passwords and encryption keys, should never be stored in source code. Instead, they should be generated dynamically and provided to the application through other means, such as environment variables. Many cloud platforms also offer a specialized service to store secrets for applications that are deployed in the cloud.
When secrets are stored in source code, they are in a risky position, because:
- They can be accidentally shipped as part of an application, or pushed to a public repository. It is important to remember that any application that is shipped to a client can be reverse engineered, no matter how well it is obfuscated.
- It is hard to follow best practices when secrets are stored in source code, such as updating the secret periodically and using independent secrets for each environment.
Detailed information on secret management can be found in the OWASP cheatsheet series [2].
Incorrect usage of encryption algorithms
Cryptographic algorithms are only secure when they are used correctly. For example, many cryptographic algorithms require a key and nonce. For these algorithms, a pair of key and nonce should never be reused. An example of this are AES-CTR and AES-GCM. If an attacker is able to obtain different ciphertexts that were encrypted with the same key and nonce, the attacker may be able to decrypt them without knowing the key. For some algorithms, the requirements are even more strict. ECDSA requires that the nonce is a secret random value without bias. If it is not, an attacker may even be able to recover the key. Sometimes, the security of an algorithm is broken by an implementation flaw. For AES-CBC, it is important that an attacker cannot distinguish a ciphertext with valid padding from one with invalid padding. If the server tells the client whether a given ciphertext is decrypted successfully or not, through a direct or indirect way (such as timing), an attacker can use this to decrypt any ciphertext that was encrypted by the server. In short, before using an encryption algorithm, it is important to understand its pitfalls and how it must be used. Always consult an expert when in doubt.Insecure random number generators
Random number generators (RNGs) are often used to generate secrets, such as session keys, MFA codes and password reset tokens. If an attacker can predict the next secret, they can often bypass authentication or decrypt sensitive data.
Unfortunately, many RNGs are not secure. If an attacker can recover the seed, or observe enough output of the RNG, they can predict all numbers that will be generated in the future and (usually) all numbers that were generated in the past. This is even possible when only parts of the RNG output are exposed to the attacker [3].
For secrets, it is important to use an RNG that is cryptographically secure, which means that its output cannot be predicted. Whether an RNG is secure is often explained in its documentation. So, before you use an RNG:
- Consider whether its output must be kept secret
- If it must be kept secret, check whether the RNG is cryptographically secure
Here are some examples of RNGs that are secure and RNGs that are not:
Language | Secure | Insecure |
Python |
|
|
PHP |
|
|
Java |
|
|
C# |
|
|
Golang |
|
|
Because it is so difficult to get everything right, Securance offers various security services, including code reviews and pentesting. If you would like us to assess the security of your application, feel free to reach out by contacting us below.
Sources:
[1]: https://owasp.org/www-project-top-ten/
[2]: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
[3]: https://github.com/fx5/not_random
