Reino: Security Features
La seguridad de un software no es un software de seguridad. Nos preocupamos de cuestiones como la autenticación, el control de acceso, la confidencialidad, la criptografía y la gestión de privilegios.
Key Management: Empty PBE Password
Abstract
El uso de una clave generada por una función de derivación de claves basada en contraseña a la que se pasó un valor vacío para su argumento de contraseña podría comprometer la seguridad del sistema de una forma que no es fácil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.dotnet.key_management_empty_pbe_password
Abstract
Se utiliza una contraseña vacía para generar una clave a partir de una función de derivación de claves basada en contraseñas (PBKDF). El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma difícil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("");
...
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_pbe_password
Abstract
El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma que no es fácil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basa exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
const pbkdfPassword = "";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_pbe_password
Abstract
Se utiliza una contraseña vacía para generar una clave a partir de una función de derivación de claves basada en contraseñas (PBKDF). El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma difícil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 2: Algunas API de nivel inferior pueden requerir pasar la longitud de determinados argumentos, además de los valores de los argumentos, de manera que una función pueda leer el valor del argumento como un número de bytes consecutivos, empezando por la ubicación del argumento en la memoria. El siguiente código pasa a cero como el argumento de longitud de contraseña a una PBKDF criptográfica:
En este caso, incluso si
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
...
CCKeyDerivationPBKDF(kCCPBKDF2,
"",
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 2: Algunas API de nivel inferior pueden requerir pasar la longitud de determinados argumentos, además de los valores de los argumentos, de manera que una función pueda leer el valor del argumento como un número de bytes consecutivos, empezando por la ubicación del argumento en la memoria. El siguiente código pasa a cero como el argumento de longitud de contraseña a una PBKDF criptográfica:
...
CCKeyDerivationPBKDF(kCCPBKDF2,
password,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
En este caso, incluso si
password contiene un valor de contraseña seguro y administrado adecuadamente, al pasar su longitud como cero se obtendrá un valor de contraseña vacío, null o con alguna otra debilidad inesperada.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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_pbe_password
Abstract
Se utiliza una contraseña vacía para generar una clave a partir de una función de derivación de claves basada en contraseñas (PBKDF). El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma difícil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
Cualquiera que tenga acceso al código puede determinar que genera una o más claves criptográficas basadas en un argumento de contraseña vacío. Además, cualquiera que tenga incluso técnicas básicas de descifrado podría obtener acceso con éxito a cualquier recurso protegido por las claves infractoras. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...
Cualquiera que tenga acceso al código puede determinar que genera una o más claves criptográficas basadas en un argumento de contraseña vacío. Además, cualquiera que tenga incluso técnicas básicas de descifrado podría obtener acceso con éxito a cualquier recurso protegido por las claves infractoras. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_empty_pbe_password
Abstract
Se utiliza una contraseña vacía para generar una clave a partir de una función de derivación de claves basada en contraseñas (PBKDF). El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma difícil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_pbe_password
Abstract
Se utiliza una contraseña vacía para generar una clave a partir de una función de derivación de claves basada en contraseñas (PBKDF). El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma difícil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_pbe_password
Abstract
Se utiliza una contraseña vacía para generar una clave a partir de una función de derivación de claves basada en contraseñas (PBKDF). El establecimiento de contraseñas vacías a una PBKDF compromete la seguridad del sistema de una forma difícil de resolver.
Explanation
Nunca es una buena idea pasar un valor vacío como argumento de contraseña a una función de derivación de claves basada en contraseñas criptográfica (PBKDF). En este caso, la clave derivada se basará exclusivamente en la sal proporcionada (debilitándola considerablemente) y complicará en gran medida la solución del problema. Una vez que el código dañino está en ejecución, a menudo la contraseña vacía no se puede cambiar sin aplicar revisiones al software. Si la cuenta protegida por una clave derivada basada en una contraseña vacía se ve comprometida, los propietarios del sistema podrían verse obligados a elegir entre la seguridad y la disponibilidad.
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 2: Algunas API de nivel inferior pueden requerir pasar la longitud de determinados argumentos, además de los valores de los argumentos, de manera que una función pueda leer el valor del argumento como un número de bytes consecutivos, empezando por la ubicación del argumento en la memoria. El siguiente código pasa a cero como el argumento de longitud de contraseña a una PBKDF criptográfica:
En este caso, incluso si
Ejemplo 1: El siguiente código pasa la cadena vacía como el argumento de contraseña a una PBKDF criptográfica:
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
No solo permitirá a cualquiera con acceso al código determinar que genere una o varias claves criptográficas basadas en un argumento de contraseña vacía, sino que cualquier usuario malintencionado podrá obtener acceso a cualquier recurso protegido por las claves dañinas. Si, además, un usuario malintencionado tiene acceso al valor de sal que se usa para generar cualquiera de las claves basadas en una contraseña vacía, le resultará muy sencillo descifrar esas claves. Una vez lanzado el programa, no hay forma de cambiar la contraseña vacía, a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema. Incluso si los usuarios malintencionados tuvieran solo acceso al ejecutable de la aplicación, podrían saber que se está usando una contraseña vacía.
Ejemplo 2: Algunas API de nivel inferior pueden requerir pasar la longitud de determinados argumentos, además de los valores de los argumentos, de manera que una función pueda leer el valor del argumento como un número de bytes consecutivos, empezando por la ubicación del argumento en la memoria. El siguiente código pasa a cero como el argumento de longitud de contraseña a una PBKDF criptográfica:
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
En este caso, incluso si
password contiene un valor de contraseña seguro y administrado adecuadamente, al pasar su longitud como cero se obtendrá un valor de contraseña vacío, null o con alguna otra debilidad inesperada.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 - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] 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
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] 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
[32] 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
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_pbe_password