Definición
El cifrado es transformar datos para que solo quien tenga la clave correcta pueda volver a leerlos.
Y la primera distinción, porque se confunden constantemente:
Cifrado = reversible. Con la clave, recuperas el original. Se usa cuando necesitas leer el dato después.
Hash = irreversible. No hay forma de volver atrás. Se usa cuando solo necesitas comprobar si algo coincide.
Las contraseñas no se cifran, se hashean. Si un sistema puede enviarte tu contraseña olvidada por email, la está guardando de forma recuperable, y eso es un fallo grave por sí solo.
Simétrico y asimétrico
Simétrico. La misma clave cifra y descifra. Rápido y eficiente, ideal para grandes volúmenes. Su problema es logístico: cómo le haces llegar la clave al otro sin que la intercepten.
Asimétrico. Dos claves relacionadas: una pública que se reparte y una privada que se guarda. Lo cifrado con una solo se descifra con la otra. Resuelve el problema del reparto de claves y es mucho más lento.
En la práctica se combinan, y así funciona HTTPS: se usa el asimétrico solo para acordar una clave simétrica, y a partir de ahí todo el tráfico va con la rápida.
En tránsito y en reposo
En tránsito. Los datos viajando por la red. Es lo que da HTTPS, y hoy es el mínimo indiscutible.
En reposo. Los datos guardados en disco: base de datos, copias de seguridad, ficheros.
Ese segundo se descuida mucho más. Una copia de seguridad sin cifrar en un almacenamiento externo contiene todo lo sensible de la empresa en un fichero que puede acabar en cualquier sitio.
Ejemplo práctico
En un sistema de gestión, la pregunta útil no es «¿ciframos todo?», sino qué hay que cifrar y para protegerse de qué.
Lo que aprendí: cifrar la base de datos entera protege del robo físico del disco, y no protege de casi nada más. Si un atacante entra por la aplicación, esta descifra los datos para trabajar con ellos y se los sirve igual. El cifrado en reposo es una capa contra un escenario concreto, no una solución general.
Los tres sitios donde sí cambia algo de verdad:
Copias de seguridad que salen fuera. Van a un almacenamiento de terceros y se guardan meses. Ahí el cifrado es obligatorio.
Campos concretos muy sensibles. Datos bancarios, documentación de salud. Cifrarlos a nivel de campo limita el daño si se filtra una tabla.
Secretos de configuración. Claves de API, credenciales de terceros. Ver gestión de secretos.
El segundo aprendizaje, y es la regla que nunca hay que romper: no inventes tu propio cifrado. Usa las bibliotecas estándar del lenguaje con los algoritmos recomendados y sus parámetros por defecto. Un esquema criptográfico casero parece funcionar perfectamente —cifra y descifra— y puede ser trivial de romper para quien sepa. Es de las pocas áreas de la programación donde la creatividad es el enemigo.
Y una advertencia sobre las claves: cifrar mueve el problema, no lo elimina. Los datos pasan a estar seguros si la clave lo está. Una clave guardada junto a los datos que protege es un candado con la llave puesta — y es exactamente lo que ocurre cuando alguien la escribe en el propio código.
Errores comunes
- Cifrar contraseñas en vez de hashearlas.
- Inventarse el algoritmo.
- Guardar la clave junto a los datos o dentro del código.
- Copias de seguridad sin cifrar almacenadas fuera.
- Creer que cifrar la base de datos protege de un ataque a la aplicación.
- Usar algoritmos obsoletos. Lo que era seguro hace quince años puede no serlo hoy.
- No prever la rotación de claves. Si nunca has cambiado una clave, no sabes si podrías.
Cuándo aplicarlo
Siempre en tránsito, sin excepciones. En reposo, en copias que salgan de tu control y en los campos que de verdad lo justifiquen.
Y con la pregunta que ordena la decisión: ¿de qué escenario concreto me estoy protegiendo? Cifrar sin responderla produce complejidad sin seguridad — y una clave más que perder.
