Kingdom: Security Features

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

Password Management: Lack of Key Derivation Function

Abstract

The application is configured to create digests for passwords that use a cryptographic hash function.

Explanation

A cryptographic hash function is a one-way function that is considered practically impossible to invert; that is, to recreate the input data from its digest value alone. These hash functions were considered safe to store passwords in the past because even if an attacker could access the digest value for the original password, they wouldn't be able to recover the original password from the digest value. This was proved wrong, as attackers used a dictionary attack with "rainbow tables" so that they could pre-compute the digest value for millions of words/phrases and after they got a password digest, they only had to compare its value with the values stored within the "rainbow tables" to get back the original password. As the computational power of personal computers increased over time, this technique became obsolete and was rapidly replaced with a brute-force attack enabled by "GPU" units. Attackers no longer need to pre-compute the password hashes (which was almost impossible with the use of salts); now they have enough computational power to brute-force possible passwords byte by byte.

Example 1: The following shows an application configured to use Java Simplified Encryption (Jasypt) Password encoder that just uses an MD5 digest under the covers:


...
    <param name="foo" class="org.jasypt.util.password.BasicPasswordEncoder">
        ...
    </param>  
...

References

[1] Wikipedia Key derivation function

[2] Wikipedia PBKDF2

[3] OWASP Password Storage Cheat Sheet

[4] IETF PBKDF2 RFC

[5] Standards Mapping - Common Weakness Enumeration CWE ID 261

[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287

[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287

[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287

[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287

[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287

[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287

[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000196, CCI-001199

[13] Standards Mapping - FIPS200 IA

[14] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection

[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-28 Protection of Information at Rest (P1)

[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-28 Protection of Information at Rest

[17] 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.3 Single or Multi Factor One Time Verifier Requirements (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.10.1 Service Authentication Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)

[18] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography

[19] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography

[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.2.1, Requirement 6.2.4

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.2.1, Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4

[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7.1 - Use of Cryptography

[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.2 - Sensitive Data Protection, Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design

[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 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

[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001740 CAT I, APSC-DV-002330 CAT II

[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)

[61] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage

desc.config.java.password_management_lack_of_key_derivation_function

Abstract

Cryptographic hash functions should not be used on their own to generate digests for stored passwords.

Explanation

A cryptographic hash function is a one-way function that is considered practically impossible to invert; that is, to recreate the input data from its digest value alone. These hash functions were considered safe to store passwords in the past because even if an attacker could access the digest value for the original password, they wouldn't be able to recover the original password from the digest value. This was proved wrong, as attackers used a dictionary attack with "rainbow tables" so that they could pre-compute the digest value for millions of words/phrases and after they got a password digest, they only had to compare its value with the values stored within the "rainbow tables" to get back the original password. As the computational power of personal computers increased over time, this technique became obsolete and was rapidly replaced with a brute-force attack enabled by "GPU" units. Attackers no longer need to pre-compute the password hashes (which was almost impossible with the use of salts); now they have enough computational power to brute-force possible passwords byte by byte.

Example 1: The following example shows how a password hash is calculated and stored in the database for later login usage:


import hashlib

def register(request):
  password = request.GET['password']
  username = request.GET['username']

  hash = hashlib.md5(get_random_salt() + ":" + password).hexdigest()
  store(username, hash)
...