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.

Weak Cryptographic Hash: Empty Salt

Abstract

Una sal vacía anula su propia finalidad y la seguridad del sistema puede quedar comprometida de una forma que no es fácil de resolver.

Explanation

Nunca es una buena idea utilizar una sal vacía. No es solo que una sal vacía frustre su propia finalidad, sino que todos los desarrolladores del proyecto pueden ver la sal. Esto hace que solucionar el problema sea extremadamente difícil porque una vez que el código está en producción, no es fácil modificar la sal. Si los atacantes conocen el valor de sal, pueden calcular “tablas arco iris” para la aplicación y determinar fácilmente los valores con hash.

Ejemplo 1: El código siguiente define una sal vacía para el hash de contraseña:


...
define('SECURE_AUTH_SALT', "");
...

Este código se ejecuta correctamente, pero todo aquel que tenga acceso a él puede ver la sal. Una vez que se haya distribuido el programa, no hay otro modo de cambiar la sal vacía. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema.

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 759

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001188, CCI-002450

[3] Standards Mapping - FIPS200 MP

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

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1), SC-23 Session Authenticity (P1)

[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection, SC-23 Session Authenticity

[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.4.1 Credential Storage Requirements (L2 L3), 2.4.2 Credential Storage Requirements (L2 L3), 2.4.5 Credential Storage Requirements (L2 L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)

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

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

[10] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage

[11] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage

[12] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage

[13] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure

[14] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure

[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[24] 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

[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography, Control Objective 7.4 - Use of Cryptography

[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective 7.4 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design

[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective 7.4 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design

[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 759

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

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

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

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

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

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

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

[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II, APSC-DV-002290 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002030 CAT II, APSC-DV-002290 CAT II

desc.semantic.php.weak_cryptographic_hash_empty_salt

Abstract

Una sal vacía anula su propia finalidad y la seguridad del sistema puede quedar comprometida de una forma que no es fácil de resolver.

Explanation

Nunca es una buena idea utilizar una sal vacía. Una sal vacía no solo anula su propia finalidad, sino que también permite que todos los desarrolladores de proyectos vean sal y además dificulta muchísimo la solución del problema. Una vez que el código está en producción, no es fácil modificar sal. Si los usuarios malintencionados conocen el valor de sal, pueden calcular "tablas arco iris" para la aplicación y determinar más fácilmente los valores con hash.

Ejemplo 1: El siguiente código utiliza una sal vacía para hashes de contraseña:


import hashlib, binascii

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

  hash = hashlib.md5("%s:%s" % ("", password,)).hexdigest()
  store(username, hash)
...

Este código se ejecutará correctamente, pero todo aquel que tenga acceso a él también tendrá acceso a sal. Una vez que se haya distribuido el programa, no hay otro modo de cambiar la sal vacía. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema.