El login es la puerta de entrada de casi cualquier aplicación, y paradójicamente suele ser lo que se arma más rápido: un formulario, una tabla de usuarios y listo. Los problemas aparecen en los bordes, en lo que pasa cuando alguien olvida su clave, cuando prueba mil combinaciones o cuando deja la sesión abierta en una computadora ajena.
Cómo guardar las contraseñas
Nunca se guarda la contraseña, se guarda una huella. Pero no cualquier huella: un hash rápido de propósito general (de los pensados para verificar archivos) permite probar miles de millones de combinaciones por segundo si la base se filtra. Hay que usar funciones diseñadas para contraseñas, que son deliberadamente lentas y consumen memoria, como las que ofrecen las bibliotecas de criptografía reconocidas. Usá la que recomiende tu plataforma, con los parámetros de costo vigentes.
La sal es un valor aleatorio único por usuario que se combina con la contraseña antes de calcular el hash. Evita que dos usuarios con la misma clave tengan la misma huella y vuelve inútiles las tablas precalculadas. Las bibliotecas buenas la generan y la guardan por vos; si tu código la manipula a mano, desconfiá.
Tampoco escribas tu propio esquema de hash ni mezcles contraseñas en registros o mensajes de error.
Intentos, doble factor y recuperación
Un login sin límites invita a probar claves una y otra vez. Aplicá límites de intentos por cuenta y por origen, con esperas crecientes en vez de bloqueos permanentes (que un atacante podría usar para dejar afuera a usuarios legítimos). Registrá los fallos y alertá cuando hay picos.
El segundo factor de autenticación reduce mucho el daño de una contraseña robada o reutilizada. Ofrecelo, y exigilo para cuentas con privilegios. Los códigos generados por una aplicación o las llaves físicas son mejores que los mensajes de texto, que tienen debilidades conocidas.
La recuperación de cuenta es un segundo login disfrazado, y suele ser el eslabón más débil. Revisá:
- Que el enlace de restablecimiento sea largo, aleatorio, de un solo uso y con vencimiento corto.
- Que no se base en preguntas de seguridad con respuestas deducibles, como el nombre de una mascota.
- Que al cambiar la contraseña se cierren las sesiones activas.
- Que se avise por correo al titular cada vez que cambia una credencial.
Mensajes que no revelan de más
"El usuario no existe" y "contraseña incorrecta" son dos mensajes distintos que le dicen a un atacante qué correos están registrados. Usá un mensaje único para el login ("credenciales inválidas") y el mismo criterio en la recuperación ("si el correo existe, te enviamos instrucciones"). Los tiempos de respuesta también filtran información: si buscar un usuario inexistente tarda menos que verificar una clave, la diferencia se puede medir.
Identificadores de sesión
Después de iniciar sesión, el servidor entrega algo que identifica a ese usuario en las peticiones siguientes. Ese identificador funciona como una contraseña temporal, así que:
- Tiene que ser aleatorio, generado con una fuente criptográficamente segura, nunca derivado de datos predecibles como un contador o la fecha.
- Se regenera al iniciar sesión, para evitar que alguien fije un identificador antes de que la víctima se autentique.
- Tiene vencimiento por inactividad y un máximo absoluto.
- Se puede revocar del lado del servidor: al cerrar sesión, al cambiar la clave, o cuando el usuario pide cerrar todas sus sesiones.
Esto último es el punto débil de los tokens autocontenidos: si el servidor no guarda nada, no hay forma sencilla de invalidarlos antes de su vencimiento. Mantené vidas cortas y pensá desde el principio cómo vas a revocar.
Cookies bien configuradas
Si la sesión viaja en una cookie, activá tres atributos:
- Secure: la cookie solo se envía por conexiones cifradas.
- HttpOnly: el JavaScript de la página no puede leerla, lo que limita el efecto de un XSS.
- SameSite: restringe el envío en peticiones originadas desde otros sitios, lo que frena buena parte de los ataques de falsificación de peticiones. Elegí el valor más estricto que tolere tu flujo.
Sumá una protección explícita con tokens anti falsificación en las acciones que cambian estado.
Qué revisar en tu sistema
Una revisión de media hora alcanza para detectar lo grave: cómo se guardan las contraseñas, si hay límites de intentos, qué mensajes aparecen, qué atributos tienen las cookies, qué pasa con la sesión al cerrar sesión y al cambiar la clave. Y si podés, no construyas todo esto desde cero: un componente de autenticación mantenido y revisado por mucha gente tiene menos agujeros que el que armes un viernes a la tarde.