Ir al contenido principal

Los riesgos de usar passwords hard-coded

El uso de passwords hardcodeados o hardcoded, escritos directamente en el código fuente de una aplicación, es una mala práctica que compromete la seguridad y privacidad de los datos y los usuarios. 

Veamos los principales riesgos de esta práctica y algunos ejemplos de cómo evitarla.

¿Qué son los passwords hardcodeados y por qué se usan?

Los passwords hardcodeados o hardcoded son aquellos que se escriben directamente en el código fuente de una aplicación web, sin usar ningún mecanismo de cifrado, almacenamiento seguro o configuración externa. Por ejemplo, si una aplicación web necesita conectarse a una base de datos, se podría usar un password hardcodeado de la siguiente forma:


Python
# Ejemplo de password hardcodeado en Python
import mysql.connector

# Conexión a la base de datos usando un password hardcodeado
conn = mysql.connector.connect(
    host="localhost",
    user="admin",
    password="123456" # Password hardcodeado
)

Los passwords hardcodeados se usan a veces por comodidad, simplicidad o principalmente por desconocimiento de las mejores prácticas de desarrollo seguro. Algunos desarrolladores pueden pensar que los passwords hardcodeados son seguros porque el código fuente no es accesible para los usuarios o porque el password es complejo. Sin embargo, estas suposiciones son erróneas y pueden tener graves consecuencias.

¿Cuáles son los riesgos de usar un password hardcodeado?

El uso de passwords hardcodeados en aplicaciones web implica varios riesgos, entre los que destacamos los siguientes:

  • Exposición del código fuente: El código fuente de una aplicación web puede ser expuesto por diversos motivos, como errores, vulnerabilidades, ataques, filtraciones o auditorías. Si el código fuente contiene passwords hardcodeados, estos quedarán al descubierto y podrán ser usados por personas malintencionadas para acceder a los recursos protegidos por estos passwords, como bases de datos, servidores, APIs, etc.
  • Dificultad de cambio: Los passwords hardcodeados son difíciles de cambiar, ya que requieren modificar el código fuente y volver a compilar o desplegar la aplicación web. Esto puede ser un problema si se detecta una brecha de seguridad, si se necesita actualizar el password por motivos de política o si se quiere rotar el password periódicamente. Además, si el password hardcodeado se usa en varias partes del código o en varias aplicaciones, el cambio será más complejo y propenso a errores.
  • Falta de control: Los passwords hardcodeados no permiten un control adecuado sobre quién y cómo se usa el password. No se puede restringir el acceso al password a ciertos usuarios, roles o entornos, ni se puede monitorizar el uso del password para detectar actividades sospechosas o anómalas. Tampoco se puede revocar el acceso al password en caso de que se pierda, se comparta o se robe.

¿Cómo evitar el uso de passwords hardcodeados?

Para evitar el uso de passwords hardcodeados en aplicaciones web, se recomienda seguir las siguientes buenas prácticas:

  1. Usar mecanismos de cifrado: Los passwords no deben escribirse en texto plano en el código fuente, sino que deben cifrarse usando algoritmos seguros y claves secretas. De esta forma, aunque el código fuente se exponga, los passwords no serán legibles. Por ejemplo, se podría usar el módulo cryptography de Python para cifrar y descifrar los passwords.
  2. Usar mecanismos de almacenamiento seguro: Los passwords no deben almacenarse en el código fuente, sino en lugares seguros, como archivos de configuración, variables de entorno, servicios de secretos o almacenes de credenciales. De esta forma, se puede separar el password del código, facilitar su cambio y controlar su acceso. Por ejemplo, se podría usar el servicio Azure Key Vault para almacenar y recuperar los password.
  3. Usar mecanismos de autenticación alternativos: Los passwords no son la única forma de autenticarse en una aplicación web, sino que existen otras opciones más seguras y convenientes, como el uso de tokens, certificados, llaves o identidades. De esta forma, se puede evitar el uso de passwords y aprovechar los beneficios de estos mecanismos, como la caducidad, la renovación, la revocación o la delegación. Por ejemplo, se podría usar el protocolo OAuth 2.0 para obtener y usar tokens de acceso.

Conclusión

El uso de password hardcodeados en aplicaciones web es una mala práctica que puede poner en riesgo la seguridad y la privacidad de los datos y los usuarios. Para evitar esta práctica, se deben seguir las buenas prácticas de cifrado, almacenamiento seguro y autenticación alternativa. De esta forma, se podrá mejorar la seguridad, la flexibilidad y el control de las aplicaciones web.


Este artículo está relacionado con los artículos:


Puedes encontrar más recomendaciones sobre el manejo de passwords en:
CWE correspondiente a esta vulnerabilidad:

Comentarios

Entradas populares de este blog

Reporte SOC 2 Type 2 en la seguridad de la información

La importancia del reporte SOC 2 Type 2 en la seguridad de la información En un entorno digital donde la confianza y la seguridad son fundamentales, las organizaciones deben demostrar que sus prácticas de protección de datos cumplen con estándares rigurosos. Uno de estos estándares es el SOC 2 (Service Organization Control 2) Type 2 , un informe que evalúa cómo una empresa maneja la seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad de los datos. Este reporte es esencial para empresas que manejan información sensible, ya que proporciona evidencia objetiva sobre su capacidad para proteger la información de sus clientes y socios comerciales. ¿Qué es un reporte SOC 2 Type 2? El SOC 2 Type 2  es un informe de auditoría que evalúa los controles internos de una organización  relacionados con la seguridad de la información. Desarrollado por la AICPA (American Institute of Certified Public Accountants), este informe sigue los Criterios de Servicios...

Managing Cyber Risks: Third-Party and End-User Challenges

🔐 Managing Cyber Risks: Third-Party and End-User Challenges Our organizations face a multitude of cyber threats that can compromise data integrity, disrupt operations, and damage reputations. Among the most challenging risks are those posed by third parties and end users. These risks often operate outside the direct control of the organization, yet their actions or inactions can have profound security implications. Understanding these risks and implementing effective controls is essential for building a resilient cybersecurity posture. 🔗  Third-Party Risks arises when organizations rely on external vendors, suppliers, or service providers who have access to our sensitive systems or data. These partners may not adhere to the same security standards, creating vulnerabilities that can be exploited by malicious actors. High-profile breaches, such as those involving supply chain attacks, have underscored the dangers of insufficient oversight in third-party relationships. The challeng...

Compendio de términos computacionales / Compendium of computational terms

Publicación: 22/julio/2023 Última edición: 12/junio/2026 2FA: Two-Factor Authentication 3DEA: Triple Data Encryption Algorithm 3DES: Triple DES 3PS: Third Person Shooter AAM: Agentic Access Management AC: Access Control ACL: Access Control Lists AES: Advanced Encryption Standard AI: Artificial Intelligence AIoT: Artificial Intelligence of Things AitM:  Adversary-in-the-Middle AML: Anti-Money Laundering AOC: Attestation Of Compliance API: Application Programming Interface APT: Advanced Persistent Threat ASCII: American Standard Code for Information Interchange ASM: Attack Surface Management ASPM: Application Security Posture Management ASV: Approved Scanning Vendor for PCI ATM: Automated Teller Machine ATT$CK: Adversarial Tactics, Techniques, and Common Knowledge AV: Antivirus AWS: Amazon Web Service B2B: Business to Business B2C: Business to Consumer BAS: Breach and Attack Simulation BAU: Business As Usual BBP: Bug Bounty Program BCM: Business Continuity Manage...