Auditoría del almacenamiento de contraseñas: hashing, sal y migración segura

Qué revisa una auditoría de almacenamiento de contraseñas (y por qué debería importarte)

Un buen almacenamiento de contraseñas significa algo simple: si alguien roba tu base de datos de usuarios, igual no podrá usar esas contraseñas.

Tu app nunca debe almacenar contraseñas en texto legible. Debe guardar un hash unidireccional que sea lento de adivinar, único por usuario y preparado para que puedas mejorarlo con el tiempo.

Una auditoría de almacenamiento de contraseñas revisa toda la cadena, no solo la pantalla de login. En código heredado (especialmente el generado rápidamente por herramientas de IA), los inicios de sesión pueden parecer funcionar mientras el almacenamiento es inseguro. Un prototipo podría hacer hash con una función rápida, reutilizar la misma sal o registrar secretos accidentalmente durante la depuración. Nada de eso rompe el flujo feliz, pero puede convertir una fuga de datos en una ola de tomas de cuentas.

Si los atacantes consiguen hashes débiles, pueden ejecutar ataques de adivinanza offline. No necesitan golpear tus servidores ni disparar límites de tasa. Simplemente prueban conjeturas en sus máquinas hasta encontrar coincidencias. Una vez que rompen una contraseña, a menudo la prueban en otros sitios porque la gente reutiliza contraseñas.

Un buen almacenamiento suele incluir:

• Un algoritmo moderno y lento para contraseñas (no un hash de propósito general como MD5 o SHA-1).
• Una sal aleatoria y única por contraseña, almacenada junto al hash.
• Pepper opcional: un secreto separado guardado fuera de la base de datos.
• Versionado claro para poder cambiar ajustes después sin romper logins.
• Sin exposiciones accidentales (logs, eventos de analytics, mensajes de error, backups).

La secuencia más segura es auditar primero, migrar después. La auditoría identifica lo que tienes hoy (algoritmo, ajustes, dónde vive el código, cómo funcionan los resets), y luego eliges un plan de actualización.

Un plan común es “rehash en el próximo login”: los usuarios siguen iniciando sesión normalmente y, cuando se verifica la contraseña, actualizas su hash almacenado al nuevo estándar.

Señales de alerta que puedes detectar rápido en código heredado

No necesitas reescribir todo para encontrar los mayores riesgos. Una auditoría rápida suele empezar con búsquedas simples que revelan si las contraseñas se almacenan o manejan de forma insegura.

La señal más urgente es cualquier cosa que sugiera que las contraseñas pueden recuperarse. Si ves contraseñas guardadas directamente en una columna de la base de datos, registradas en consola, enviadas a analytics o “encriptadas” con algo reversible (por ejemplo, AES con una clave almacenada), trátalo como un incidente. Las contraseñas deben almacenarse solo como hashes unidireccionales.

Otro problema común es el uso de hashes rápidos. Podrías ver MD5, SHA-1 o SHA-256 aplicado directamente a la contraseña. Aunque “parezca hasheado”, los hashes rápidos están hechos para ser veloces, lo que los hace fáciles de romper a escala. Si el código dice hash(password) y nada más, es una señal fuerte de que no se está usando correctamente una función de hash para contraseñas.

Comprobaciones rápidas que detectan muchos de los peores problemas:

• Menciones de md5, sha1, sha256(password) o helpers como "encryptPassword".
• Salidas de hash que siempre tienen la misma longitud y formato, sin signo de una sal por usuario.
• Contraseñas o tokens de reseteo apareciendo en logs, reports de errores o volcados de base de datos.
• Secretos (claves JWT, contraseñas de BD, PEPPER=...) hardcodeados en el repo o en config committeada.
• Código de login que asume un único formato de hash y no tiene ruta de actualización.

La falta o mala implementación de salado es sutil pero fácil de detectar una vez sabes qué buscar. Si dos usuarios con la misma contraseña terminan con el mismo valor almacenado, el sistema probablemente no usa sal, usa una sal global o una sal predecible. Una configuración sana produce resultados almacenados distintos incluso para contraseñas idénticas.

Un ejemplo práctico: heredas una app Node y encuentras la columna users.password llena de cadenas hex de 64 caracteres. El handler de login hace sha256(req.password) y lo compara con la base de datos. “Funciona”, pero es vulnerable y no te da una forma segura de mejorar sin planear soporte para múltiples formatos de hash.

Finalmente, verifica si el flujo de login puede manejar cambios. Si el código no puede verificar hashes legacy y después rehashear con un método más fuerte en el siguiente login exitoso, las actualizaciones se vuelven riesgosas y pueden causar bloqueos de cuentas.

Mapea dónde se manejan contraseñas y flujos de reseteo

Una auditoría va más rápido si empiezas con un mapa simple: cada lugar donde una contraseña o token de reseteo se crea, envía, procesa o almacena. En código heredado, las partes riesgosas a menudo no están en una carpeta “auth”. Están esparcidas por formularios de UI, rutas API, jobs en background y herramientas admin.

Empieza listando cada punto de entrada donde una contraseña puede entrar al sistema y luego confirma cada uno en el código y en las configs de producción. Lugares comunes: flujos de signup, login (incluyendo rutas SSO de fallback), reseteo y recuperación de contraseña, herramientas de admin/soporte e importaciones o migraciones (subidas CSV, sincronización con CRM, scripts de seed).

Después, localiza dónde viven los datos relacionados con contraseñas en la base de datos. Revisa columnas obvias como password, password_hash y hashed_password, pero también busca tablas legacy y copias sombra (por ejemplo, una antigua users_legacy aún leída por un job en background). Si encuentras más de un campo de hash de contraseña, anota cuál se usa realmente en el login.

El logging es otra fuga común. Busca en tu código y en la configuración de monitoreo cualquier cosa que pueda capturar valores sensibles: logs de peticiones, eventos de analytics, reports de error e impresiones de depuración. Un fallo realista: un handler de fallo de login registra el body completo "para troubleshooting", enviando en silencio contraseñas en texto claro a los logs.

Los reseteos de contraseña merecen su propio mini-mapa porque los tokens son fáciles de manejar mal. Identifica cómo se generan (fuente de aleatoriedad), dónde se almacenan (fila de DB, cache, payload del link de email) y cómo expiran. También verifica si son de un solo uso y qué pasa si un token se reutiliza después de cambiar la contraseña.

Finalmente, dibuja el límite del servicio. Anota cada componente que toca auth: cliente frontend, API gateway, servicio de auth, workers en background (email, SMS) y cualquier proveedor de identidad de terceros. En proyectos generados por IA, también es común encontrar endpoints de auth extra dejados atrás durante iteraciones, así que incluye rutas antiguas y flags de característica deshabilitados en tu escaneo.

Verifica el algoritmo de hashing y sus ajustes

Una auditoría de almacenamiento de contraseñas empieza con una pregunta directa: ¿estás usando una función de hashing para contraseñas o un hash de propósito general?

Si ves MD5, SHA-1, SHA-256 o algo enmarcado como “encrypt password”, considéralo un problema serio. Esas herramientas no están diseñadas para frenar a los atacantes.

Prefiere hashes dedicados como Argon2id, bcrypt o scrypt. Están diseñados para ser costosos de romper, por lo que los hashes filtrados cuestan mucho más trabajo convertirlos en contraseñas.

Cómo saber qué tienes a partir del hash almacenado

La mayoría de sistemas almacenan el algoritmo y los ajustes dentro de la cadena del hash, así que un vistazo rápido a un valor de la base de datos puede decirte mucho.

Patrones comunes:

• Argon2id suele comenzar con $argon2id$ e incluye memoria e iteraciones.
• bcrypt suele comenzar con $2a$, $2b$ o $2y$ e incluye un cost como 10 o 12.
• scrypt puede mostrar $scrypt$ o parámetros como N, r y p según la librería.

Si ves una cadena hex de longitud fija (por ejemplo, 32 o 64 caracteres hex) sin separadores $, puede ser un hash general o un esquema personalizado que requiere revisión más profunda.

Revisa los ajustes, no solo el nombre

La elección del algoritmo es solo la mitad de la historia. Argon2id puede ser débil si la memoria es ínfima. bcrypt puede ser débil si el cost es muy bajo.

Busca dónde se configura el factor de trabajo y si puedes cambiarlo sin redeploy. Las configuraciones más sanas ponen los costos en config, usan el método de verificación incorporado de la librería (no una comparación manual de strings) y comparan en tiempo constante.

También confirma que el endpoint de login tiene defensas básicas: rate limiting por cuenta y por IP, además de reglas de bloqueo sensatas. Bloqueos cortos y temporales suelen ser más seguros que bloqueos permanentes.

Comprueba el salado: unicidad, almacenamiento y aleatoriedad

Una auditoría debe confirmar una regla: cada hash de contraseña debe tener su propia sal única y aleatoria.

Si dos usuarios eligen la misma contraseña, sus hashes almacenados deberían verse diferentes. Si coinciden, algo anda mal.

Unicidad: una sal por contraseña, sin excepciones

Las sales evitan que los atacantes usen tablas precomputadas y hacen que romper en masa sea mucho más difícil. Eso solo funciona cuando las sales no se reutilizan.

Un problema común en código heredado es una sal única hardcodeada en un archivo de config o una “sal por defecto” reutilizada para cada usuario. Una comprobación rápida es sacar una muestra pequeña de hashes almacenados (incluso 20–50) y ver si comparten un segmento de sal idéntico o un prefijo repetido que sugiera reutilización. Si encuentras repetición, trátalo como un bug de seguridad.

Almacenamiento: embebida en el hash vs columna separada

Muchos formatos modernos almacenan la sal dentro de la propia cadena de hash. Por ejemplo, bcrypt y Argon2 típicamente incluyen algoritmo, parámetros de coste, la sal y el hash en un solo campo. Eso es normal.

Algunos sistemas guardan la sal en una columna separada junto al hash. También puede estar bien, siempre que sea por usuario y no nula o con un valor por defecto compartido. El riesgo con columnas separadas es la reutilización accidental a través de migraciones, defaults del ORM o scripts de seed.

Comprobaciones prácticas que captan la mayoría de problemas:

• Confirma que cada usuario tiene un valor de sal diferente (o una sal embebida distinta dentro de la cadena de hash).
• Confirma que las sales se generan al establecer o resetear la contraseña, no al arrancar la app.
• Asegúrate de que la longitud de la sal coincide con las expectativas del algoritmo.
• Garantiza que el código usa una fuente aleatoria criptográficamente segura.
• Evita formatos personalizados de sal que concatenen manualmente strings.

La aleatoriedad importa tanto como la unicidad. Si la sal viene de fuentes predecibles (timestamps, usernames, IDs incrementales), los atacantes pueden adivinarla.

Un fallo realista en prototipos generados por IA es un helper como salt = Math.random().toString(36) o un SALT="abc" copiado por archivos. Parece aleatorio, pero no es seguro.

Si necesitas cambiar cómo se generan o almacenan las sales, hazlo de forma que los usuarios existentes sigan pudiendo iniciar sesión normalmente y luego actualiza sus hashes de forma segura en el siguiente login exitoso.

Decide sobre el pepper y cómo almacenar el secreto de forma segura

Un pepper es un valor secreto añadido a la contraseña antes de hashear. A diferencia de la sal (única por usuario y almacenada con el hash), el pepper se comparte entre muchos usuarios y debe guardarse solo en el servidor.

El pepper ayuda especialmente si te preocupa una fuga de base de datos y cracking offline. Es útil en apps heredadas donde no confías del todo en lo que se generó o donde los secretos pueden haberse expuesto.

El pepper puede volverse contraproducente si lo tratas como una cadena de config normal. Si el pepper se filtra (hardcodeado en el repo, impreso en logs, copiado en una app cliente), ganas poco y añades riesgo. También puede causar una caída si un despliegue elimina o cambia el pepper: de repente nadie puede iniciar sesión.

Guarda el pepper como un secreto real:

• Mantenlo fuera de la base de datos y del control de código fuente.
• Cárgalo desde variables de entorno o un gestor de secretos usado por tu hosting.
• Limita el acceso al pequeño conjunto de personas y servicios que lo necesitan.
• Nunca lo envíes al navegador o a la app móvil.
• Evita loguear cualquier cosa que pueda revelarlo (ni siquiera valores parciales).

Planea la rotación antes de lanzar. Rotar un pepper es más difícil que rotar una API key porque afecta cada verificación de contraseña.

El enfoque más seguro es soporte de pepper dual durante una ventana: acepta el pepper antiguo y el nuevo, y actualiza a los usuarios gradualmente. En el login, verifica con el pepper nuevo primero. Si falla, verifica con el pepper antiguo. Si el antiguo funciona, rehasea y guarda usando el pepper nuevo. Esto permite rotación sin forzar resets de contraseña.

Anota quién puede ver o cambiar el pepper, dónde se define en cada entorno y cuál es el plan de rollback si un deploy rompe los logins.

Paso a paso: migrar hashes de forma segura en el próximo login

Un plan seguro de “rehash en el próximo login” te permite aceptar las contraseñas existentes y luego mejorar el almacenamiento sin forzar un reseteo masivo. Es una de las correcciones con mayor impacto porque reduce el riesgo rápidamente sin interrumpir a los usuarios.

1) Detecta si un hash almacenado es legacy o moderno

Haz que el valor en la base de datos sea auto-descriptivo. La mayoría de formatos ya lo son. Por ejemplo, bcrypt suele empezar con $2a$ o $2b$, y Argon2 con $argon2id$.

Si tu sistema legacy usaba algo custom (como sha1(salt+password)), añade una columna explícita hash_version para saber qué estás verificando.

2) Verifica usando el método legacy solo cuando haga falta

En el login, comprueba el formato/version almacenada primero. Si es moderno, verifica normalmente. Si es legacy, ejecuta solo el verificador legacy para ese usuario.

Cuidado con el “doble hashing” (hashear la contraseña entrante antes de pasarla al verificador). Asegúrate de que el verificador recibe la cadena de contraseña en crudo exactamente una vez.

3) Rehashea con el nuevo algoritmo y sobrescribe al tener éxito

Si la verificación legacy tiene éxito, rehasea inmediatamente con tu elección nueva y ajustes actuales (por ejemplo Argon2id o bcrypt con un cost más fuerte) y escríbelo de vuelta en el formato moderno.

Haz la actualización atómica y ligada al ID de usuario para que dos logins no compitan. Un enfoque simple es “verificar primero, luego actualizar hash y hash_version en una sola escritura”.

if verify(password, stored_hash, version) == true:
  new_hash = hash_new(password)
  update users set password_hash = new_hash, hash_version = "v2" where id = user_id
  allow_login()
else:
  deny_login()

Ejemplo concreto: heredas un prototipo que usaba SHA-1 sin sal más un secreto global. Mantienes ese verificador solo para validar cuentas antiguas. Tras el primer login exitoso, la fila se actualiza a Argon2id y futuros logins nunca vuelven a tocar SHA-1.

4) Añade observabilidad sin filtrar secretos

Mide el progreso y los problemas, pero nunca registres contraseñas ni hashes completos. Loggea solo contadores y resultados seguros, como logins legacy exitosos (se rehaseó), logins legacy fallidos, logins modernos exitosos/fallidos, número de usuarios aún en formato legacy y errores de rehash (falla de escritura, mismatch de versión).

Errores comunes de migración que bloquean usuarios

Una actualización de hash debe ser invisible para los usuarios. La mayoría de bloqueos ocurren cuando la migración cambia comportamiento, no seguridad.

Un gran error es forzar un reset de contraseña sin plan. Si invalidas todos los hashes existentes, personas que ya no tienen acceso a su email antiguo (o que usan SSO a veces) quedan atrapadas. Si debes forzar resets tras una brecha, aún necesitas una vía alternativa, mensajes claros y soporte para casos límite como emails no verificados.

Otra trampa común es actualizar hashes en intentos fallidos. Con una contraseña incorrecta no conoces el texto plano correcto, así que no puedes rehashear nada de forma segura. Peor aún, algo de código sobrescribe el hash almacenado con basura derivada del input erróneo, bloqueando al usuario incluso si luego escribe la contraseña correcta.

Los cambios en la normalización de contraseñas también pueden romper logins silenciosamente. Diferencias pequeñas como recortar espacios, cambiar reglas de mayúsculas o variar el manejo Unicode pueden hacer que la misma contraseña se hashee distinto que antes. Un ejemplo realista: una app heredada recortaba espacios finales en el signup pero no en el login. Tras una reescritura, ambos lados empezaron a recortar y algunos usuarios que usaban intencionalmente un espacio final no pudieron iniciar sesión jamás.

Finalmente, vigila los logins concurrentes y las condiciones de carrera durante el rehash. Si dos dispositivos inician sesión al mismo tiempo, ambos pueden intentar actualizar el hash. Si tu actualización no es atómica, una petición puede sobrescribir a la otra o fallar dejando la cuenta inconsistente.

Una lista corta para evitar bloqueos:

• Rehashear solo después de una comprobación de contraseña exitosa.
• Mantener las reglas de normalización exactamente iguales durante la migración.
• Guardar el pepper solo en servidor, nunca en código cliente.
• Hacer la actualización del hash atómica (una escritura, protegida por el hash actual esperado).
• Loggear y alertar sobre fallos de migración sin bloquear logins válidos.

Comprobaciones rápidas antes de desplegar los cambios

Antes de lanzar cualquier trabajo sobre contraseñas, haz una pasada práctica que capture los errores que los usuarios notan de inmediato: logins fallidos, reseteos rotos y fugas accidentales en logs.

Prueba el flujo de login y rehash con entradas reales y sucias. No te fíes de una cuenta por el camino feliz. Prueba contraseñas muy largas (200+ caracteres), Unicode, cuentas antiguas que no han entrado en meses y usuarios creados por distintas vías (signup, import admin, OAuth luego establecer contraseña). Confirma que los errores de "contraseña incorrecta" son genéricos y consistentes y no revelan si una cuenta existe.

Los reseteos de contraseña merecen su propia verificación porque el código heredado a menudo almacena tokens en texto claro. Trata los tokens de reseteo como contraseñas: almacena solo un hash del token y compara hasheando lo que envía el usuario. Verifica que los tokens expiran cuando deben, que son de un solo uso y que no pueden reproducirse. Un escenario simple: solicita dos reseteos seguidos, usa el primer token y confirma que el segundo queda rechazado.

No lances sin un plan de rollback. Haz un backup fresco y escribe exactamente cómo revertirás si los logins se disparan o los tickets de soporte explotan. También confirma que tu actualización “rehash on next login” se comporta de forma segura si falla a medias (por ejemplo, la contraseña se verifica pero la escritura a BD falla). Los usuarios deberían poder iniciar sesión en el siguiente intento.

Finalmente, ejecuta una comprobación básica de abuso. Añade límites de tasa en endpoints de login y reseteo y asegúrate de que patrones sospechosos se marquen (muchos intentos, muchas solicitudes de reseteo, fallos repetidos desde una IP). Revisa logs y tracking de errores: nunca deben incluir contraseñas crudas, tokens de reseteo ni cabeceras de autorización completas, ni siquiera en modo debug.

Próximos pasos: completa la auditoría y fortalece código AI-heredado

Si heredaste una app generada por IA, trata la autenticación como lo que más daño puede causarte rápidamente. Una auditoría de almacenamiento de contraseñas suele ser la forma más rápida de encontrar problemas que conducen a tomas de cuentas.

Un patrón común es un prototipo que llega con auth parcheada: settings de hashing débiles, secretos hardcodeados y un flujo de reseteo que puede ser abusado. La app funciona en una demo, pero no es segura en producción.

Prioriza en un orden sensato. Primero, elimina secretos expuestos, bloquea cualquier lógica de fallback de login insegura y arregla rutas de inyección alrededor de endpoints relacionados con auth. Luego migra usuarios gradualmente para no forzar reseteos masivos.

Si quieres a un experto para revisar y arreglar rápido, ayuda preparar acceso al repo (o una exportación limpia), la rama que planeas desplegar, una forma de ejecutar la app localmente (env vars, BD de prueba), un par de cuentas de prueba (incluida una cuenta legacy si tienes hashes antiguos) y notas sobre dónde viven los secretos hoy (config de hosting, archivos env, settings de CI).

Si tratas con un codebase heredado generado por IA y no sabes qué se almacena realmente, FixMyMess (fixmymess.ai) se enfoca en diagnosticar y reparar apps creadas por IA, incluyendo lógica de autenticación, manejo de secretos y migraciones seguras “rehash on next login”. Ofrecen una auditoría de código gratuita para identificar problemas antes de que hagas cambios, con la mayoría de proyectos completados en 48–72 horas.

Un estado claro de “hecho” ayuda a mantener el trabajo enfocado:

• Las nuevas contraseñas siempre usan el hash y los ajustes aprobados.
• Los logins exitosos actualizan automáticamente los hashes legacy.
• Los flujos de reseteo y cambio de contraseña están probados y tienen límites de tasa.
• No hay contraseñas en texto claro, ni cifrado reversible, ni secretos expuestos.
• El conteo de hashes legacy tiende a cero a medida que los usuarios activos inician sesión.

Si puedes nombrar tu método de hashing actual pero no sus ajustes, o no sabes cuántos usuarios siguen en hashes legacy, es una señal para pausar y auditar antes del próximo release.