Kingdom: Security Features

Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management.

351 items found
Weaknesses
Abstract
Failure to detect and block automated attacks can enable an attacker to conduct brute force attacks or trigger denial of service conditions.
Explanation
All web forms in the application must be protected against automated submissions. An attacker can automatically submit fill and submit registration forms to create fake accounts or overwhelm the database. Contact and messaging forms that do not prevent automated form submissions can be used to spam the application administrators or users. Automated password cracking programs can target login forms with ineffective anti-automation mechanisms. Programmers must always assume that all user interfaces will be abused by attackers in order to find weaknesses.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 799
[2] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.2.1 General Authenticator Requirements (L1 L2 L3)
[3] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Anti-automation (WASC-21)
desc.dynamic.xtended_preview.insufficient_anti_automation
Abstract
The application configuration should ensure that SSL is used for all access controlled pages.
Explanation
If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL.

There are three common ways for SSL to be bypassed:

- A user manually enters URL and types "HTTP" rather than "HTTPS".

- Attackers intentionally send a user to an insecure URL.

- A programmer erroneously creates a relative link to a page in the application, failing to switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.)
References
[1] A. Taylor et al. J2EE & Java: Developing Secure Web Applications with Java Technology (Hacking Exposed) Osborne/McGraw-Hill
[2] Standards Mapping - Common Weakness Enumeration CWE ID 5
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000068, CCI-001453, CCI-002418, CCI-002420, CCI-002421, CCI-002422, CCI-002890, CCI-003123
[4] Standards Mapping - FIPS200 CM, SC
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-17 Remote Access (P1), MA-4 Nonlocal Maintenance (P2), SC-8 Transmission Confidentiality and Integrity (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-17 Remote Access, MA-4 Nonlocal Maintenance, SC-8 Transmission Confidentiality and Integrity
[8] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.2.5 General Authenticator Requirements (L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.3.1 Sensitive Private Data (L1 L2 L3), 9.1.1 Communications Security Requirements (L1 L2 L3), 9.2.2 Server Communications Security Requirements (L2 L3), 14.1.3 Build (L2 L3), 14.4.5 HTTP Security Headers Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M3 Insufficient Transport Layer Protection
[11] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[12] Standards Mapping - OWASP Top 10 2007 A9 Insecure Communications
[13] Standards Mapping - OWASP Top 10 2010 A9 Insufficient Transport Layer Protection
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 4.1, Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 4.1, Requirement 6.3.1.4, Requirement 6.5.9
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 4.1, Requirement 6.5.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 4.1, Requirement 6.5.4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 4.1, Requirement 6.5.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 4.1, Requirement 6.5.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 4.1, Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 4.2.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 4.2.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective C.4.1 - Web Software Communications
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Transport Layer Protection (WASC-04)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.j2ee_misconfiguration_insecure_transport
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following uses an empty encryption key:


...
encryptionKey = "".
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
var encryptionKey:String = "";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.actionscript.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses an empty encryption key:


...
char encryptionKey[] = "";
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cpp.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
<cfset encryptionKey = "" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cfml.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, changing the empty encryption key requires a software patch. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
key := []byte("");
block, err := aes.NewCipher(key)
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, changing the empty encryption key requires a software patch, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
private static String encryptionKey = "";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
var crypto = require('crypto');
var encryptionKey = "";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
"",
0,
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code initializes an encryption key variable to an empty string.

...
$encryption_key = '';

$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Windows Data Protection Microsoft
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.



Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.sql.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code initializes an encryption key variable to an empty string.

...
from Crypto.Ciphers import AES
cipher = AES.new("", AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a password-based key derivation function with a key length of zero, which produces an empty encryption key:


require 'openssl'
...
dk = OpenSSL::PKCS5::pbkdf2_hmac_sha1(password, salt, 100000, 0) # returns an empty string
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"",
0,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
Dim encryptionKey As String
Set encryptionKey = ""
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.vb.key_management_empty_encryption_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
EXPORTING
if_algorithm = 'SHA3'
if_key = space
RECEIVING
ro_object = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...


The code shown in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
string hmacKey = "";
byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
hmac.Key = keyBytes;
...
}
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.dotnet.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
Never use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


import "crypto/hmac"
...
hmac.New(md5.New, []byte(""))
...


The code in Example 1 might run successfully, but anyone who has access to it can determine that it uses an empty HMAC key. After the program ships, there is no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
private static String hmacKey = "";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty HMAC key to generate the HMAC hash:

...
let hmacKey = "";
let hmac = crypto.createHmac("SHA256", hmacKey);
hmac.update(data);
...


The code in Example 1 might run successfully, but anyone with access to it might figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


...
CCHmac(kCCHmacAlgSHA256, "", 0, plaintext, plaintextLen, &output);
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


import hmac
...
mac = hmac.new("", plaintext).hexdigest()
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', '', data)
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


...
CCHmac(UInt32(kCCHmacAlgSHA256), "", 0, plaintext, plaintextLen, &output)
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_hmac_key
Abstract
Using a key generated by a password-based key derivation function that was passed an empty value for its password argument might compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.dotnet.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("");
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_pbe_password
Abstract
Providing an empty password to a PBKDF compromises system security in a way that is not easily to remedy.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


const pbkdfPassword = "";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)


Not only can anyone with access to the code determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(kCCPBKDF2,
"",
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(kCCPBKDF2,
password,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...


In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...


Anyone with access to the code can determine that it generates one or more cryptographic keys based on an empty password argument. Additionally, anyone with even basic cracking techniques might successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...


In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_pbe_password
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
encryptionKey = "lakdsljkalkjlksdfkl".
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
var encryptionKey:String = "lakdsljkalkjlksdfkl";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.actionscript.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following code performs AES encryption using a hardcoded encryption key:


...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...


Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key without a software patch. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.apex.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
string encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
algorithm.Key = keyBytes;
...
}


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.dotnet.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...


Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers have access to the executable for the application they can disassemble the code, which will contain the value of the encryption key used.
References
[1] Windows Data Protection Microsoft
[2] Encrypting Your App's Files Apple
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cpp.hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cfml.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because all of the project's developers can view the encryption key, and fixing the problem is extremely difficult. After the code is in production, changing the encryption key requires a software patch. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] MSC03-J. Never hard code sensitive information CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
private static final String encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] MSC03-J. Never hard code sensitive information CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
var crypto = require('crypto');
var encryptionKey = "lakdsljkalkjlksdfkl";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_hardcoded_encryption_key
Abstract
Hardcoded passwords can compromise system security in a way that is difficult to remedy.
Explanation
Never hardcode passwords. Not only does it expose the password to all of the project's developers, it also makes fixing the problem extremely difficult. After the code is in production, a program patch is probably the only way to change the password. If the account the password protects is compromised, the system owners must choose between security and availability.
Example 1: The following JSON uses a hardcoded password:


...
{
"username":"scott"
"password":"tiger"
}
...


This configuration may be valid, but anyone who has access to the configuration will have access to the password. After the program is released, changing the default user account "scott" with a password of "tiger" is difficult. Anyone with access to this information can use it to break into the system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.json.password_management_hardcoded_password
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
NSString encryptionKey = "lakdsljkalkjlksdfkl";
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example 1: The following code uses a hardcoded encryption key to encrypt information:


...
$encryption_key = 'hardcoded_encryption_key';

//$filter = new Zend_Filter_Encrypt('hardcoded_encryption_key');
$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...


This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key ('hardcoded_encryption_key') unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.



Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.sql.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example 1: The following code uses a hardcoded encryption key to encrypt information:

...
from Crypto.Ciphers import AES
encryption_key = b'_hardcoded__key_'
cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...


This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key _hardcoded__key_ unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example 1: The following code uses a hardcoded encryption key:


require 'openssl'
...
encryption_key = 'hardcoded_encryption_key'
...
cipher = OpenSSL::Cipher::AES.new(256, 'GCM')
cipher.encrypt
...
cipher.key=encryption_key
...


This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key "hardcoded_encryption_key" unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
let encryptionKey = "YELLOW_SUBMARINE"
...
Example 2: The following code performs AES encryption using a hardcoded encryption key:


...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"YELLOW_SUBMARINE",
16,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...


Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application they could extract the encryption key value.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following example shows an encryption key inside a .pem file:


...
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQCtVacMo+w+TFOm0p8MlBWvwXtVRpF28V+o0RNPx5x/1TJTlKEl
...
DiJPJY2LNBQ7jS685mb6650JdvH8uQl6oeJ/aUmq63o2zOw=
-----END RSA PRIVATE KEY-----
...


Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.regex.universal.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
Dim encryptionKey As String
Set encryptionKey = "lakdsljkalkjlksdfkl"
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.vb.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following example shows an encryption key inside the secrets.yml file of a Ruby on Rails configuration:


...
production:
secret_key_base: 0ab25e26286c4fb9f7335947994d83f19861354f19702b7bbb84e85310b287ba3cdc348f1f19c8cdc08a7c6c5ad2c20ad31ecda177d2c74aa2d48ec4a346c40e
...


Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.yaml.key_management_hardcoded_encryption_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
EXPORTING
if_algorithm = 'SHA3'
if_key = 'secret_key'
RECEIVING
ro_object = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret_key" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
string hmacKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
hmac.Key = keyBytes;
...
}


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "hmacKey" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.dotnet.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys can compromise system security in a way that is not easy to remedy.
Explanation
Never hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:


import "crypto/hmac"
...
hmac.New(sha256.New, []byte("secret"))
...


This code runs successfully, but anyone who has access to the source has access to the HMAC key. After the program ships, there is no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
private static String hmacKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "hmacKey" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] MSC03-J. Never hard code sensitive information CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 321
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 IA
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[17] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[18] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[39] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[40] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key makes it available to anyone with access to the source, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

const hmacKey = "a secret";
const hmac = createHmac('sha256', hmacKey);
hmac.update(data);
...


This code runs successfully, but anyone with access to it has access to the HMAC key. After the program ships, there is likely no way to change the hardcoded hmacKey unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:


...
CCHmac(kCCHmacAlgSHA256, "secret", 6, plaintext, plaintextLen, &output);
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:


import hmac
...
mac = hmac.new("secret", plaintext).hexdigest()
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', 'secret_key', data)
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret_key" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:


...
CCHmac(UInt32(kCCHmacAlgSHA256), "secret", 6, plaintext, plaintextLen, &output)
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - Common Weakness Enumeration CWE ID 321
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 IA
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[16] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[17] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_hardcoded_hmac_key
Abstract
A hardcoded password is used to generate a key from a password-based key derivation function (PBKDF). Providing a hardcoded password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("password", salt,100000);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.dotnet.key_management_hardcoded_pbe_password
Abstract
A hardcoded password is used to generate a key from a password-based key derivation function (PBKDF). Providing a hardcoded password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("password");
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_hardcoded_pbe_password
Abstract
Generating and using a cryptographic key based on a hardcoded password can compromise system security in a way that is not easy to remedy.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


const pbkdfPassword = "a secret";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)


Not only can anyone with access to the code determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_hardcoded_pbe_password
Abstract
Generating and using a cryptographic key based on a hardcoded password may compromise system security in a way that is not easy to remedy.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(kCCPBKDF2,
"secret",
6,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_hardcoded_pbe_password
Abstract
A hardcoded password is used to generate a key from a password-based key derivation function (PBKDF). Providing a hardcoded password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "hardcodedpassword");
...


Anyone with access to the code can determine that it generates one or more cryptographic keys based on a hardcoded password argument. Additionally, anyone with even basic cracking techniques might successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_hardcoded_pbe_password
Abstract
A hardcoded password is used to generate a key from a password-based key derivation function (PBKDF). Providing a hardcoded password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', 'password', salt, 100000)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_hardcoded_pbe_password
Abstract
A hardcoded password is used to generate a key from a password-based key derivation function (PBKDF). Providing a hardcoded password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


...
key = OpenSSL::PKCS5::pbkdf2_hmac('password', salt, 100000, 256, 'SHA256')
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_hardcoded_pbe_password
Abstract
Generating and using a cryptographic key based on a hardcoded password may compromise system security in a way that is not easy to remedy.
Explanation
Never pass a hardcoded value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based mostly on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the hardcoded password often cannot be changed without patching the software. If an account protected by a derived key based on a hardcoded password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a hardcoded value as the password argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"secret",
6,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a hardcoded password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a hardcoded password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the hardcoded password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a hardcoded password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003310 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_hardcoded_pbe_password
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
var encryptionKey:ByteArray = null;
...
var aes.ICipher = Crypto.getCipher("aes-cbc", encryptionKey, padding);
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.actionscript.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key. Not only does using a null encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a null encryption key:


...
char encryptionKey[] = null;
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.cpp.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it is extremely difficult to fix the problem. After the offending code is in production, changing the null encryption key requires a software patch. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
aes.NewCipher(nil)
...


Anyone with access to the code can determine that it uses a null encryption key. Additionally, anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
SecretKeySpec key = null;
....
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
var crypto = require('crypto');
var encryptionKey = null;
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
nil,
0,
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Assigning null to encryption key variables is a bad idea because it can allow attackers to expose sensitive and encrypted information. Not only does using a null encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code initializes an encryption key variable to null.


...
$encryption_key = NULL;

$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...

Anyone who has access to the code would be able to determine that it uses a null encryption key, and anyone employing even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Windows Data Protection Microsoft
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.



Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.sql.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Assigning None to encryption key variables is a bad idea because it can allow attackers to expose sensitive and encrypted information. Not only does using a null encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code initializes an encryption key variable to null.

...
from Crypto.Ciphers import AES
cipher = AES.new(None, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...


Anyone who has access to the code would be able to determine that it uses a null encryption key, and anyone employing even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key. Not only does using a null encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Anyone who has access to the code would be able to determine that it uses a null encryption key, and anyone employing even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key. Not only does using a null encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
nil,
0,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - Common Weakness Enumeration CWE ID 321
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[10] Standards Mapping - FIPS200 IA
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[16] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_null_encryption_key
Abstract
Null encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use a null encryption key because it significantly reduces the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, a software patch is required to change the null encryption key. If an account that is protected by the null encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using a null encryption key:


...
Dim encryptionKey As String
Set encryptionKey = vbNullString
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...


Not only will anyone who has access to the code be able to determine that it uses a null encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the null encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null encryption key.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.vb.key_management_null_encryption_key
Abstract
Generating and using a cryptographic key based on a null password may compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to pass a null value as the password argument to a cryptographic password-based key derivation function. In this scenario, the resulting derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the null password often cannot be changed without patching the software. If an account protected by a derived key based on a null password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a null value as the password argument to a cryptographic password-based key derivation function:


...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword(null);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a null password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a null password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the null password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_null_pbe_password
Abstract
Generating and using a cryptographic key based on a null password may compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to pass a null value as the password argument to a cryptographic password-based key derivation function. In this scenario, the resulting derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the null password often cannot be changed without patching the software. If an account protected by a derived key based on a null password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a null value as the password argument to a cryptographic password-based key derivation function:


...
CCKeyDerivationPBKDF(kCCPBKDF2,
nil,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a null password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a null password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the null password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_null_pbe_password
Abstract
Generating and using a cryptographic key based on a null password may compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to pass a null value as the password argument to a cryptographic password-based key derivation function. In this scenario, the resulting derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the null password often cannot be changed without patching the software. If an account protected by a derived key based on a null password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes a null value as the password argument to a cryptographic password-based key derivation function:


...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
nil,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on a null password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on a null password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the null password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of a null password.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_null_pbe_password
Abstract
Cryptographic encryption or signing private keys should not be stored in plain text.
Explanation
Private keys used for encryption or signing should be considered sensitive data and should be encrypted with a strong passphrase prior to storage. This prevents unauthorized access by both attackers in the event of theft or a leak, as well as by users with insufficient permissions.

Example 1: The following code exports an RSA private key using an unencrypted PEM format:


from Crypto.PublicKey import RSA

key = RSA.generate(2048)
f = open('mykey.pem','w')
f.write(key.exportKey(format='PEM'))
f.close()
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 311
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000201, CCI-002450
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[10] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[11] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[13] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[27] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001820 CAT I, APSC-DV-002010 CAT II, APSC-DV-003100 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001820 CAT I, APSC-DV-002010 CAT II, APSC-DV-003100 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_unencrypted_private_key
Abstract
Cryptographic encryption or signing private keys should not be stored in plain text.
Explanation
Private keys used for encryption or signing should be considered sensitive data and should be encrypted with a strong passphrase prior to storage. This prevents unauthorized access by both attackers in the event of theft or a leak, as well as by users with insufficient permissions.

Example 1: The following code exports an RSA private key using an unencrypted PEM format:


require 'openssl'

key = OpenSSL::PKey::RSA.new 2048
File.open('mykey.pem', 'w') do |file|
file.write(key.to_pem)
end
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 311
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000201, CCI-002450
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[10] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[11] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[13] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[27] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001820 CAT I, APSC-DV-002010 CAT II, APSC-DV-003100 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001820 CAT I, APSC-DV-002010 CAT II, APSC-DV-003100 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_unencrypted_private_key
Abstract
A Kubernetes component leaks system information.
Explanation
If profiling is enabled, a component provides performance metrics through a web interface. The performance metrics reveal system data that help an adversary form a plan of attack. Either the --profiling flag is not present in the command to start the component or the flag is set to true.
References
[1] Kubernetes Components The Kubernetes Authors
[2] Kubernetes API Server The Kubernetes Authors
[3] Kubernetes controller manager The Kubernetes Authors
[4] Standards Mapping - CIS Kubernetes Benchmark Recommendation 1.2.17
[5] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [17] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), SC-8 Transmission Confidentiality and Integrity (P1), SI-11 Error Handling (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, SC-8 Transmission Confidentiality and Integrity, SI-11 Error Handling
[14] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.yaml.kubernetes_misconfiguration_api_server_profiling.base
Abstract
The Kubelet configuration prevents the Kubelet from configuring iptables.
Explanation
By default, Kubelets automatically make the required changes to iptables based on the networking options in Pod configurations. Setting makeIPTablesUtilChains to enabled:false in a Kubelet configuration prevents the Kubelet from managing network traffic between containers and the rest of the world. This prevents the Kubelet from enforcing the necessary network security requirements and setting up the connectivity requested by containers.

Example 1: The following Kubelet configuration prevents a Kubelet from making the required changes to iptables because of the setting makeIPTablesUtilChains: false.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
makeIPTablesUtilChains: false
References
[1] Set Kubelet parameters via a config file The Kubernetes Authors
[2] Kubelet The Kubernetes Authors
[3] Standards Mapping - CIS Kubernetes Benchmark Recommendation 4.2.6
[4] Standards Mapping - Common Weakness Enumeration CWE ID 284
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 CM
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1), CM-6 Configuration Settings (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement, CM-6 Configuration Settings
[10] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.3 Access Control Architectural Requirements (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3500 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3500 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3500 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3500 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3500 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3500 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3500 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.yaml.kubernetes_misconfiguration_automated_iptables_management_disabled.base
Abstract
A Kubernetes component leaks system information.
Explanation
If profiling is enabled, a component provides performance metrics through a web interface. The performance metrics reveal system data that help an adversary form a plan of attack. Either the --profiling flag is not present in the command to start the component or the flag is set to true.
References
[1] Kubernetes Components The Kubernetes Authors
[2] Kubernetes API Server The Kubernetes Authors
[3] Kubernetes controller manager The Kubernetes Authors
[4] Standards Mapping - CIS Kubernetes Benchmark Recommendation 1.3.2
[5] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [17] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), SC-8 Transmission Confidentiality and Integrity (P1), SI-11 Error Handling (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, SC-8 Transmission Confidentiality and Integrity, SI-11 Error Handling
[14] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.yaml.kubernetes_misconfiguration_api_server_profiling.base
Abstract
Containerized applications can write to the container's host file system.
Explanation
By default, a Kubernetes container runtime prevents applications from writing to the root file system of the container. The readOnlyRootFilesystem: false setting disables this restriction, which allows an attacker to tamper with the local file system or write malicious executable to disk.

Example 1: The following manifest sets the readOnlyRootFilesystem field to false, which permits applications inside a container to write data to the local disk.

...
kind: Pod
...
spec:
containers:
- name: ...
...
securityContext:
readOnlyRootFilesystem: false
...
References
[1] Pod Security Context The Kubernetes Authors
[2] Standards Mapping - Common Weakness Enumeration CWE ID 284
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[14] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[15] Standards Mapping - OWASP Top 10 2007 A10 Failure to Restrict URL Access
[16] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 285
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3480.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3480.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3480.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3480.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3480.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3480.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3480.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.yaml.kubernetes_misconfiguration_host_write_access.base
Abstract
The AlwaysPullImages admission controller is not enabled in a Kubernetes API server.
Explanation
Pulling a container image from a registry typically requires authorization. Kubernetes nodes, however, cache all images of previously started containers. An attacker can bypass the required authorization by starting a container with a cached image. The AlwaysPullImages admission controller can prevent this bypass.

Example 1: The following configuration starts a Kubernetes API server without the AlwaysPullImages admission controller in the --enable-admission-plugins flag.

...
kind: Pod
...
spec:
containers:
- command:
- kube-apiserver
...
- --enable-admission-plugins=PodNodeSelector,LimitRanger
...
References
[1] Kubernetes API Server The Kubernetes Authors
[2] Using Admission Controllers The Kubernetes Authors
[3] Standards Mapping - CIS Kubernetes Benchmark Recommendation 1.2.11
[4] Standards Mapping - Common Weakness Enumeration CWE ID 264
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [25] CWE ID 862
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [18] CWE ID 862
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[8] Standards Mapping - FIPS200 CM, SC
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[16] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[17] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[18] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2, Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 285
[34] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 863
[35] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.yaml.kubernetes_misconfiguration_image_authorization_bypass
Abstract
A Kubernetes API Server is not configured with any admission controllers.
Explanation
Admission controllers validate and customize requests to a Kubernetes API Server. They can implement security controls such as rejecting unauthorized privileged requests, enforcing namespace isolation, limiting excessive resource requests, and many more. The API Server does not validate requests because there is no admission controller or the deprecated AlwaysAdmit admission controller is enabled.

Example 1: The following configuration starts a Kubernetes API server with the AlwaysAdmit admission controller.

...
kind: Pod
...
spec:
containers:
- command:
- kube-apiserver
...
- --enable-admission-plugins=AlwaysAdmit,PodSecurityPolicy
...
References
[1] Kubernetes API Server The Kubernetes Authors
[2] Using Admission Controllers The Kubernetes Authors
[3] Standards Mapping - CIS Kubernetes Benchmark Recommendation 1.2.10
[4] Standards Mapping - Common Weakness Enumeration CWE ID 1188
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-003109
[6] Standards Mapping - FIPS200 CM
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-6 Configuration Settings (P1), SA-4 Acquisition Process (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-6 Configuration Settings, SA-4 Acquisition Process
[10] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[11] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[12] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[13] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.5.3, Requirement 6.5.4, Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.5.3, Requirement 6.5.4, Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 2.3 - Secure Defaults
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 2.3 - Secure Defaults
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 2.3 - Secure Defaults
[27] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3370 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3370 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3370 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3370 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3370 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15), Server Misconfiguration (WASC-14)
desc.structural.yaml.kubernetes_misconfiguration_improper_admission_controller_access_control
Abstract
An etcd instance does not check all incoming HTTPS requests for a client certificate signed by a trusted certificate authority.
Explanation
Kubernetes keeps sensitive data in an etcd cluster. An etcd instance accepts connections from clients without certificates signed by trusted certificate authorities because the command to start the etcd with the --client-cert-auth flag is set to false.

Example 1: The following configuration starts an etcd instance and sets the --client-cert-auth flag to false.

...
spec:
containers:
- command:
...
- etcd
...
--client-cert-auth=false
...
References
[1] Operating etcd clusters for Kubernetes The Kubernetes Authors
[2] etcd Configuration flags etcd Authors
[3] Standards Mapping - CIS Kubernetes Benchmark Recommendation 2.2
[4] Standards Mapping - Common Weakness Enumeration CWE ID 297
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [25] CWE ID 295
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000166, CCI-000185, CCI-001941, CCI-001942, CCI-002418, CCI-002420, CCI-002421, CCI-002422
[11] Standards Mapping - FIPS200 CM, SC
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), IA-2 Identification and Authentication (Organizational Users) (P1), IA-5 Authenticator Management (P1), SC-8 Transmission Confidentiality and Integrity (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, IA-2 Identification and Authentication (Organizational Users), IA-5 Authenticator Management, SC-8 Transmission Confidentiality and Integrity
[15] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 9.2.1 Server Communications Security Requirements (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M3 Insufficient Transport Layer Protection
[18] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[19] Standards Mapping - OWASP Top 10 2007 A9 Insecure Communications
[20] Standards Mapping - OWASP Top 10 2010 A9 Insufficient Transport Layer Protection
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 4.1, Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 4.1, Requirement 6.3.1.4, Requirement 6.5.9
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 4.1, Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 4.1, Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 4.1, Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 4.1, Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 4.1, Requirement 6.5.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 4.2.1, Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 4.2.1, Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.2 - Sensitive Data Protection, Control Objective 7.1 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.2 - Sensitive Data Protection, Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.2 - Sensitive Data Protection, Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design, Control Objective C.4.1 - Web Software Communications
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Transport Layer Protection (WASC-04)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.yaml.kubernetes_misconfiguration_inadequate_certificate_verification.base
Abstract
A service does not enforce robust encryption in transit.
Explanation
Insufficiently protected data communication channels can put critical organizational data at risk of theft, tampering, or disclosure.
References
[1] Standards Mapping - CIS Kubernetes Benchmark Recommendation 4.2.7, Recommendation 4.2.10, Recommendation 4.2.11
[2] Standards Mapping - Common Weakness Enumeration CWE ID 319
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000068, CCI-001453, CCI-002418, CCI-002420, CCI-002421, CCI-002422, CCI-002890, CCI-003123
[7] Standards Mapping - FIPS200 CM, SC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-17 Remote Access (P1), MA-4 Nonlocal Maintenance (P2), SC-8 Transmission Confidentiality and Integrity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-17 Remote Access, MA-4 Nonlocal Maintenance, SC-8 Transmission Confidentiality and Integrity
[11] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.9.1 Communications Architectural Requirements (L2 L3), 2.2.5 General Authenticator Requirements (L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.3.1 Sensitive Private Data (L1 L2 L3), 8.1.6 General Data Protection (L3), 9.1.1 Communications Security Requirements (L1 L2 L3), 9.2.2 Server Communications Security Requirements (L2 L3), 14.4.5 HTTP Security Headers Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M3 Insufficient Transport Layer Protection
[14] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[15] Standards Mapping - OWASP Top 10 2007 A9 Insecure Communications
[16] Standards Mapping - OWASP Top 10 2010 A9 Insufficient Transport Layer Protection
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 4.1, Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 4.1, Requirement 6.3.1.4, Requirement 6.5.9
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 4.1, Requirement 6.5.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 4.1, Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 4.1, Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 4.1, Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 4.1, Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 4.2.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 4.2.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design, Control Objective C.4.1 - Web Software Communications
[32] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 319
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3250.1 CAT I, APP3250.2 CAT I, APP3250.3 CAT II, APP3250.4 CAT II, APP3260 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000160 CAT II, APSC-DV-000170 CAT II, APSC-DV-001940 CAT II, APSC-DV-001950 CAT II, APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Transport Layer Protection (WASC-04)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.iac.misconfiguration_insecure_transport.base
Abstract
The retention period for audit logs is too short.
Explanation
Log files should be kept long enough to facilitate post-incident analysis and threat detection, as well as to meet compliance requirements. The --audit-log-maxage flag defines the maximum number of days to retain old audit log files. Either the flag is not present in the command to start a Kubernetes API server or the retention period is set to less than 30 days.

Example 1: The following command starts a Kubernetes API server and sets --audit-log-maxage flag to 2 (2 days), which is too short.

...
kind: Pod
...
spec:
containers:
- command:
- kube-apiserver
...
- --audit-log-maxage=2
...
References
[1] Kubernetes API Server The Kubernetes Authors
[2] Audit Policy The Kubernetes Authors
[3] Standards Mapping - CIS Kubernetes Benchmark Recommendation 1.2.19
[4] Standards Mapping - Common Weakness Enumeration CWE ID 778
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000172
[6] Standards Mapping - FIPS200 CM
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-12 Audit Generation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-12 Audit Record Generation
[10] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 7.1.3 Log Content Requirements (L2 L3), 7.1.4 Log Content Requirements (L2 L3), 7.2.1 Log Processing Requirements (L2 L3), 7.2.2 Log Processing Requirements (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A10 Insufficient Logging and Monitoring
[17] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10, Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 10.2.1, Requirement 10.2.4, Requirement 10.3.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 10.2.1, Requirement 10.2.1.4, Requirement 10.2.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 10.2.1, Requirement 10.2.1.4, Requirement 10.2.2
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 8.2 - Activity Tracking
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 8.2 - Activity Tracking
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 8.2 - Activity Tracking
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3680.4 CAT II, APP3680.5 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3680.4 CAT II, APP3680.5 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3680.4 CAT II, APP3680.5 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3680.4 CAT II, APP3680.5 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3680.4 CAT II, APP3680.5 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3680.4 CAT II, APP3680.5 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3680.4 CAT II, APP3680.5 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000830 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000830 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000830 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000830 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000830 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000830 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000830 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000830 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000830 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000830 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000830 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000830 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000830 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000830 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000830 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.yaml.kubernetes_misconfiguration_insufficient_api_server_log_retention.base