El modelo Usuario de Escena Viva lleva desde la lección 07-02 con su email, su nombre y su rol —asistente, organizador, administrador— y sin ningún campo de contraseña. No fue un descuido: era un hueco reservado. En esta lección lo llenamos con el rigor que merece, porque el almacenamiento de contraseñas es el punto donde un fallo no se nota hasta que es un titular de prensa.

Veremos por qué un hash rápido no sirve, qué hace exactamente bcrypt, cómo se elige su factor de coste midiendo, y cómo se escriben POST /auth/registro y POST /auth/login sin filtrar qué correos existen ni cuánto tarda cada rama del código. Terminaremos con lo que más se hace mal: los tokens de verificación y de recuperación.

1. Por qué jamás se guardan contraseñas en claro
2. Qué es un hash de contraseña
3. bcrypt, scrypt y Argon2
4. bcrypt en la práctica
5. Alternativa nativa: crypto.scrypt
6. Completar el modelo Usuario
7. Política de contraseñas y esquema zod
8. POST /auth/registro y enumeración de usuarios
9. POST /auth/login y tiempos constantes
10. Límite de intentos y registros
11. Verificación de correo y recuperación
12. Errores comunes, ejercicios y conclusión

Imagina que la base escena_viva se filtra: una copia de seguridad mal permisionada, una inyección SQL, un empleado descontento. Si existe una columna contrasena con el texto tal cual, ocurren tres cosas: todas las cuentas quedan comprometidas, incluidas las de organizadores y administradores; se comprometen cuentas de otros servicios, porque la gente reutiliza contraseñas (el correo de Lucía y su clave se prueban automáticamente en decenas de sitios: eso es el relleno de credenciales); y las contraseñas siguen siendo válidas hasta que cada persona la cambie una por una.

¿Cifrarlas con una clave? Tampoco. El cifrado es reversible por diseño: existe una clave que devuelve el original, esa clave vive en el servidor, y quien roba la base suele poder robar también el servidor. Además no hay ninguna razón legítima para recuperar una contraseña: el servidor solo necesita comprobar si la que le acaban de dar es la correcta. ¿Un hash como MD5 o SHA-256? Es irreversible, sí, pero demasiado rápido:

La velocidad es virtud para verificar ficheros y desastre para contraseñas: lo que hace rápido al servidor hace rápido al atacante, y el atacante tiene GPUs. Añade que un hash sin sal de una contraseña común está precalculado en tablas arcoíris públicas (5f4dcc3b5aa765d61d8327deb882cf99 es password en cualquier buscador), y que dos usuarios con la misma contraseña producirían hashes idénticos, lo que ya es una fuga en sí misma.

Un hash de contraseña (o función de derivación de clave) se diseña con tres propiedades deliberadas:

1. Es lenta a propósito: del orden de 100–500 ms. Al usuario legítimo no le importa; al atacante que prueba millones de combinaciones lo arruina.
2. Usa una sal única por usuario: una cadena aleatoria guardada junto al hash. Anula las tablas arcoíris y hace que contraseñas iguales den hashes distintos. La sal no es secreta: su función es la unicidad.
3. Tiene un factor de coste ajustable: el hardware mejora cada año, el parámetro se sube y el algoritmo sigue sirviendo una década.
4. Los mejores añaden coste en memoria, para que no baste con poner muchos núcleos de GPU en paralelo.

Recomendación razonada: si empiezas hoy y puedes añadir la dependencia argon2, usa Argon2id, que resiste mejor el hardware especializado gracias al coste en memoria; si necesitas cero dependencias nativas, crypto.scrypt ya viene en Node y es perfectamente defendible. En Escena Viva usamos bcrypt porque es el que encontrarás en la inmensa mayoría del código existente, su API se explica sin ruido y su seguridad es adecuada con un coste bien elegido. Lo importante es el modelo; cambiar de algoritmo será un cambio localizado en un único módulo, y así lo escribiremos. Nunca es aceptable: MD5, SHA-1, «SHA-256 con sal» o cualquier invención propia a base de concatenar y rehashear.

bcrypt compila un módulo nativo; si tu despliegue lo complica (contenedores mínimos, funciones sin servidor), bcryptjs es la implementación en JavaScript puro, compatible en API y unas tres veces más lenta.

Un hash bcrypt se explica solo:

Por eso bcrypt.compare no necesita que le pases la sal ni el coste: están dentro del hash. Y por eso subir el coste no invalida los hashes antiguos: cada uno se verifica con el suyo.

El factor de coste es logarítmico: 12 significa 2^12 = 4096 iteraciones y cada punto duplica el tiempo. Regla práctica: el mayor valor que mantenga el login por debajo de unos 250 ms en tu hardware de producción. Mídelo, no lo copies:

Por qué la comparación en tiempo constante importa. En el módulo 3, con Buffers, vimos crypto.timingSafeEqual: una comparación normal (===) se detiene en el primer byte distinto, así que el tiempo revela cuántos bytes coincidían, y repitiendo la medición miles de veces se reconstruye un secreto byte a byte. bcrypt.compare compara siempre los 60 caracteres completos; la misma lógica se aplicará a los tokens de la sección 11.

Fíjate en el detalle que casi nadie incluye: guardar los parámetros junto al hash, que es exactamente lo que bcrypt hace por ti. Sin ellos, subir N invalidaría todos los hashes anteriores.

select: false convierte «no filtrar el hash» en el comportamiento por defecto en vez de en una disciplina que hay que recordar; el único sitio que lo pedirá explícitamente será el login. lowercase: true evita el fallo sutil de tener dos cuentas para el mismo correo: técnicamente la parte local es sensible a mayúsculas, pero ningún proveedor real lo aprovecha y normalizar es lo que esperan los usuarios.

Durante veinte años se exigió «8 caracteres con mayúscula, número y símbolo». El NIST cambió de opinión (SP 800-63B) porque los datos mostraron que esas reglas producen Verano2024! en todas partes: contraseñas cortas, predecibles y difíciles de recordar, que la gente acaba anotando.

Sin .strict(), un cuerpo con "rol":"administrador" podría acabar creando un administrador si alguien escribe new Usuario(req.body): es asignación masiva, y volveremos a ella en 08-06. La comprobación contra listas de contraseñas filtradas (Have I Been Pwned) se hace con k-anonimato —se envían los 5 primeros caracteres del SHA-1 y se filtra localmente, sin revelar la contraseña—; no la implementamos aquí, pero en producción tiene de las mejores relaciones coste/beneficio.

Repasa lo que no hace: no devuelve el usuario creado, no devuelve el hash, no dice si el correo existía y no acepta el cuerpo entero. Cuatro omisiones deliberadas. Las rutas, en src/rutas/autenticacion.js → { crearRutasAutenticacion }, encadenan el límite y el validar(esquema, ORIGENES_VALIDOS.CUERPO) del módulo 6 antes de cada controlador.

Responder «ese correo ya está registrado» parece amable y es una fuga de información: permite confirmar qué correos tienen cuenta antes de lanzar relleno de credenciales, y en servicios sensibles revela pertenencia. Se filtra por cuatro canales y hay que cerrarlos todos:

El compromiso honesto: esto empeora la usabilidad, y quien se registró hace un año no recibe un aviso claro. La solución correcta es que el correo lo aclare: si la cuenta ya existe, se envía un mensaje que dice «alguien intentó registrarse con tu correo; si fuiste tú, aquí tienes el enlace para recuperarla». El atacante que no controla el buzón no ve nada; el legítimo sí. Decidir es un juicio de valor: en un foro de recetas, un 409 claro es defendible; en una plataforma con datos de compra, no.

Añadimos los errores a src/errores.js, siguiendo el patrón del módulo 6:

Ampliamos la tabla ESTADO_POR_CODIGO de src/middleware/errores.js con NO_AUTENTICADO: 401, SIN_PERMISO: 403 y DEMASIADAS_PETICIONES: 429. Así un login fallido devuelve el formato de siempre:

El hash lento encarece el ataque por contraseña probada; el límite de peticiones lo encarece por intento. Hacen falta los dos:

Ojo con el bloqueo de cuenta: si bloqueas tras N fallos, has creado una denegación de servicio contra cualquier usuario cuyo correo se conozca; preferible retardo creciente, CAPTCHA a partir de un umbral y aviso por correo. En 08-06 afinamos los límites por tipo de ruta y explicamos por qué el almacén en memoria no vale con varios procesos.

Qué se registra: marca de tiempo, idPeticion (M6), correo o id de usuario, resultado y motivo genérico, IP y agente de usuario. Qué nunca: la contraseña —ni siquiera hasheada—, el hash guardado, tokens de sesión, acceso o recuperación, y el cuerpo completo de la petición. El fallo real más habitual no es escribir console.log(contrasena), sino volcar la petición entera en un middleware de depuración o en un capturador de errores; por eso conviene una lista centralizada de campos censurados: contrasena, contrasenaActual, token, authorization, cookie.

Ambos flujos usan la misma primitiva: un token de un solo uso enviado por correo. Cuatro reglas, sin excepción:

1. Aleatorio criptográfico, no Math.random() ni un UUID versión 1: randomBytes(32).
2. Se guarda hasheado (SHA-256 basta: el token ya tiene 256 bits de entropía, no hace falta lentitud), así que quien robe la base no puede usar los tokens pendientes.
3. Caduca pronto: 1 hora para recuperación, 24 h para verificación.
4. Un solo uso: se borra al consumirlo. Y al usarlo se invalidan las sesiones y refrescos existentes: si alguien había entrado con la contraseña robada, el cambio debe echarlo.

El modelo TokenCorreo guarda usuarioId, tipo (verificacion o recuperacion), hashToken (único) y expiraEn con un índice { expireAfterSeconds: 0 }, para que MongoDB borre solo los documentos caducados sin necesidad de una tarea de limpieza.

Y el cambio de contraseña estando dentro, que siempre exige la actual:

• Hashear en el cliente y enviar el hash. No sirve: el hash se convierte en la contraseña, y quien robe la base se autentica con él directamente. La contraseña viaja en claro dentro de TLS y se hashea en el servidor.
• Sal global compartida. La sal es única por usuario. Un secreto adicional de aplicación (pepper) es una capa válida, pero nunca sustituye a la sal y complica la rotación.
• Guardar la contraseña «temporalmente» en un campo, que acaba en una copia de seguridad y en un log; u olvidar select: false y devolver el usuario entero en un JSON, el modo más silencioso de filtrar hashes.
• Truncar sin avisar por el límite de 72 bytes. Dos frases de paso largas con el mismo comienzo pasarían a ser equivalentes.
• Consejo: que hashearContrasena/verificarContrasena sean el único punto que conoce el algoritmo —migrar a Argon2 será cambiar un fichero—, y al subir el coste aprovecha el login para rehashear cuando la contraseña se verifica bien: migración transparente, sin pedir nada al usuario.

Este controlador tiene cinco fallos de seguridad. Encuéntralos y explica cada uno.

Escribe verificarYActualizar(usuario, contrasenaEnClaro): verifica la contraseña y, si es correcta pero el hash usa un coste menor que configuracion.bcryptCoste, lo regenera y lo guarda. Pista: el coste está en el propio hash, entre el segundo y el tercer $.

Enumera en orden los pasos de POST /auth/recuperar/:token, que fija una contraseña nueva, indicando en cada uno qué ataque previene.

Ejercicio 1

1. Usuario.create(req.body): asignación masiva; un cuerpo con "rol":"administrador" crea un administrador. Deben extraerse los campos uno a uno desde req.datosValidados.
2. SHA-256 como hash de contraseña: rápido y sin sal, vulnerable a GPU y a tablas arcoíris. Debe ser bcrypt/scrypt/Argon2.
3. console.log de la contraseña en claro: queda en los registros para siempre.
4. res.json(usuario): devuelve el documento completo; sin select: false ni toJSON, expone el hash y campos internos.
5. Sin validación previa: ni política de longitud, ni normalización del correo, ni control de duplicados; además responde 201 revelando si el correo existía (enumeración). Fallo extra: el usuario se crea sin hashContrasena y se guarda en dos pasos; si el segundo save() falla, queda una cuenta sin credencial.

Ejercicio 2. El login es el único momento en que el servidor conoce la contraseña en claro legítimamente, así que es el único momento posible para rehashear.

Ejercicio 3

Ya existe una credencial de verdad en Escena Viva. Sabemos por qué una contraseña nunca se guarda en claro, cifrada ni con SHA-256; qué hace un hash de contraseña —lento, salado, con coste ajustable— y por qué bcrypt guarda variante, coste y sal dentro del propio hash. Hemos medido el factor de coste en lugar de copiarlo, completado el modelo Usuario con hashContrasena y select: false, escrito un esquema zod .strict() con política moderna, y construido POST /auth/registro y POST /auth/login que no filtran qué correos existen ni por el mensaje, ni por el código, ni por el tiempo. Y hemos hecho bien la parte que más se falla: tokens de un solo uso, aleatorios, hasheados en la base y con caducidad.

Pero fíjate en cómo termina hoy iniciarSesion: sabemos que es Lucía… y no hacemos nada con esa información. La siguiente petición vuelve a llegar anónima. En la lección siguiente, Sesiones y Cookies con Passport.js, lo resolvemos de la forma clásica: un identificador de sesión aleatorio en una cookie HttpOnly, el estado en el servidor, express-session con las opciones que de verdad importan, la regeneración que impide la fijación de sesión, Passport con su estrategia local, y la protección CSRF que las cookies exigen a cambio de su comodidad.