Cryptographic operations should use proven, standard algorithms rather than custom implementations.
Why is this an issue?
Non-standard cryptographic algorithms are those that have not been publicly vetted by the security community or that implement cryptographic primitives in a custom way. Creating a custom cryptographic algorithm by subclassing standard cryptographic base classes bypasses the rigorous testing and peer review that established algorithms undergo. Custom implementations are likely to contain subtle flaws that could be exploited to break the protection the algorithm is supposed to provide.
What is the potential impact?
Data compromise
When an attacker discovers a flaw in a custom cryptographic algorithm, they may be able to decrypt any data protected by it. Depending on the application, this could expose passwords, personal data, financial records, or other sensitive information.
How to fix it
This rule detects custom implementations of these types from the System.Security.Cryptography namespace:
AsymmetricAlgorithmAsymmetricKeyExchangeDeformatterAsymmetricKeyExchangeFormatterAsymmetricSignatureDeformatterAsymmetricSignatureFormatterDeriveBytesHashAlgorithmICryptoTransformSymmetricAlgorithm
Code examples
Noncompliant code example
public class CustomHash : HashAlgorithm // Noncompliant
{
private byte[] result;
public override void Initialize() => result = null;
protected override byte[] HashFinal() => result;
protected override void HashCore(byte[] array, int ibStart, int cbSize) =>
result ??= array.Take(8).ToArray();
}
Compliant solution
SHA256 mySHA256 = SHA256.Create()
Resources
Documentation
- Derived from FindSecBugs rule MessageDigest is Custom