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 ' Noncompliant
Inherits HashAlgorithm
Private fResult() As Byte
Public Overrides Sub Initialize()
fResult = Nothing
End Sub
Protected Overrides Function HashFinal() As Byte()
Return fResult
End Function
Protected Overrides Sub HashCore(array() As Byte, ibStart As Integer, cbSize As Integer)
fResult = If(fResult, array.Take(8).ToArray)
End Sub
End Class
Compliant solution
Dim mySHA256 As SHA256 = SHA256.Create()
Resources
Documentation
- Derived from FindSecBugs rule MessageDigest is Custom