Cómo protegemos tus contraseñas

En artículos anteriores, exploramos cómo HTTPS protege la ruta entre tu aplicación y nuestro servidor, y cómo SSH asegura el servidor en sí. Ahora es momento de mirar dentro del servidor: cómo Splync mantiene tu contraseña segura una vez que llega allí. Si alguien obtuviera tu contraseña, podría acceder a tu cuenta y a información sensible, incluyendo tus registros de gastos. Por eso, Splync nunca almacena contraseñas en texto plano. En su lugar, cada contraseña se transforma en una versión hashed antes de guardarla en la base de datos. ¿Qué significa esto exactamente? Hashing es una conversión unidireccional: una vez transformada, no se puede revertir al formato original. Este método es estándar en internet, desde bancos hasta grandes servicios en la nube, aunque mucha gente no sabe cómo funciona en realidad. Vamos a explorarlo con una sencilla analogía diaria.

Para entender cómo funciona la protección de contraseñas, comencemos con un método de hashing simple llamado SHA-256. Piensa en él como una licuadora que siempre mezcla los ingredientes de la misma manera. Si introduces la misma contraseña en la licuadora y presionas el botón, siempre obtendrás el mismo licuado único: una mezcla revuelta de letras y números. La idea clave es que el proceso no se puede revertir. Así como no puedes tomar un licuado y separar de nuevo el plátano y la leche originales, no puedes tomar el hash revuelto y recuperar la contraseña original.

SHA-256 es uno de los algoritmos de hashing más comunes. Por ejemplo, transforma la contraseña "splync1234" en "9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41". En milisegundos, cada vez que un usuario existente introduce una contraseña de inicio de sesión, SHA-256 siempre produce la misma contraseña hashed. La aplicación simplemente vuelve a hashear la contraseña ingresada y verifica si coincide con el hash almacenado. En ningún momento el sistema conoce la contraseña original del usuario. Pero, ¿y si un atacante pre-calcula una lista de contraseñas comunes y sus hashes (conocido como ataque de tabla arcoíris) para adivinar rápidamente las contraseñas de los usuarios? Esa preocupación es muy real. Por eso los sistemas modernos, incluidos Splync, no dependen de SHA-256 simple.

Bcrypt utiliza una sal aleatoria por usuario y codifica esa sal (y el factor de costo) directamente en la cadena hash almacenada. Piensa en bcrypt como una licuadora con una especia secreta (sal) y un motor lento (factor de trabajo), lo que hace que cada mezcla sea única y más difícil de copiar. Debido a que la sal es de 128 bits (≈3×10³⁸ posibilidades), la misma contraseña puede corresponder a un número astronómicamente grande de diferentes hashes almacenados. Esto hace que las tablas arcoíris precomputadas sean inútiles a gran escala. Durante el inicio de sesión, Splync lee la sal y el costo de la cadena bcrypt guardada, ejecuta bcrypt nuevamente en la contraseña ingresada con esos parámetros y compara el resultado con el hash almacenado. Si coinciden, la contraseña es correcta, pero debido a que bcrypt es intencionadamente lento y las sales son únicas, los ataques de fuerza bruta resultan mucho más costosos para un atacante.

Veamos cómo se ve esto en la práctica. Si hasheas la contraseña "splync1234" con bcrypt (usando costo 12), podrías obtener una cadena como esta: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. En esta cadena bcrypt, `$2b` marca la versión del algoritmo, `$12` muestra el factor de costo (cuántas veces se procesa la contraseña), `gBeouKYdue9uvvuV0HtGgeV` es la sal aleatoria única y `PymnrojMqP/wcRw28HFlGEGIQbyw7O` es la contraseña final hasheada. Debido a que el propio hash contiene la sal y el costo, Splync puede reproducir el mismo proceso de hashing para verificación extrayendo esos valores de la cadena almacenada y comparando el resultado. Por otro lado, si un atacante no conoce la sal y el costo, no puede construir una única tabla arcoíris que funcione para todos los usuarios.

Este enfoque tiene otra ventaja importante. Como Splync nunca almacena contraseñas en texto plano, incluso si la base de datos se filtrara o robara, los usuarios no estarían inmediatamente en riesgo. Los atacantes no pueden iniciar sesión directamente con los datos robados, porque lo que tienen son solo cadenas revueltas. Este diseño ofrece a los usuarios una capa extra de protección, además de las salvaguardias que ya existen alrededor del servidor. El hashing de contraseñas no es exclusivo de Splync; es el estándar en toda la industria tecnológica, utilizado por gigantes como Google, Apple y Amazon. Splync se ha construido de forma muy segura y solo será más seguro a medida que sigamos mejorando la seguridad con características como la verificación por correo electrónico, la protección contra fuerza bruta y la monitorización continua.