Esta es la parte más sensible para la seguridad de Server Manager. Esto es exactamente lo que ocurre con tus credenciales SSH en cada fase.
Cuando conectas un servidor (sin guardarlo)
El flujo predeterminado: introduces la IP del servidor, el nombre de usuario y la contraseña/clave privada en el modal de conexión, y haces clic en Conectar.
- Tus credenciales se envían a Server Manager por HTTPS
- Se mantienen en la memoria del proceso de la sesión del lado del servidor que se comunica con tu VPS
- No se escribe nada en disco. Ni en la base de datos, ni en archivos de registro, ni en caché.
- Cuando te desconectas, cierras la pestaña del navegador o la sesión caduca, las credenciales se eliminan de la memoria
Si nuestro servidor se reinicia, tus credenciales desaparecen: tendrás que reconectarte manualmente la próxima vez. Está diseñado así.
Cuando guardas un perfil de servidor (opcional)
Si marcas "Guardar este servidor" durante la conexión, ciframos tus credenciales con una frase de contraseña que solo tú conoces.
Qué se cifra
El bloque cifrado contiene tu contraseña SSH O tu clave privada + la frase de contraseña opcional de la clave. También incluye una pequeña cabecera de metadatos para que sepamos qué tipo de credencial usar.
Cómo funciona el cifrado
- Indicas una frase de contraseña al guardar (recomendamos que sea algo que no uses para nada más)
- La frase de contraseña se procesa con scrypt — una función de derivación de claves basada en contraseña, diseñada para ser deliberadamente lenta — con una sal aleatoria de 16 bytes distinta para cada servidor, para producir una clave AES de 256 bits
- Tus credenciales se cifran con AES-256-GCM (cifrado autenticado: si el texto cifrado se manipula, no se puede descifrar; sin ataques de oráculo de relleno)
- Guardamos en la base de datos el texto cifrado, la sal, el nonce GCM y la etiqueta de autenticación GCM
- Tu frase de contraseña nunca se almacena. Ni con hash, ni derivada, ni presente de ninguna forma en nuestro lado.
Cómo distinguimos entre "frase de contraseña incorrecta" y "datos manipulados"
Ambas situaciones fallan igual: falla la comprobación de la etiqueta de autenticación AES-GCM. No hay ningún verificador almacenado con el que podamos comparar tu frase de contraseña, ni ningún hash que pueda filtrarse. Frase de contraseña incorrecta = error de descifrado = la introduces de nuevo y vuelves a intentarlo.
Cuando vuelves a conectarte a un servidor guardado
Pegas tu frase de contraseña. Volvemos a derivar la clave con scrypt + la sal almacenada, desciframos el bloque de credenciales, usamos las credenciales descifradas para abrir la sesión SSH y luego eliminamos inmediatamente de la memoria las credenciales descifradas en cuanto la sesión queda establecida.
Las credenciales SSH descifradas solo existen en el código que gestiona la sesión durante la vida de la propia conexión SSH. Igual que en el flujo sin guardado descrito arriba: solo en memoria, nunca en disco.
Qué ocurre si nuestro servidor se ve comprometido
Esta es la amenaza contra la que diseñamos el sistema. En concreto:
- El atacante obtiene acceso de lectura a la base de datos: obtiene texto cifrado. Para usar cualquier credencial guardada, necesita descifrar por fuerza bruta la frase de contraseña de ese servidor. - scrypt es intencionadamente lento: cada intento de frase de contraseña consume ~100ms+ de CPU en hardware moderno. Descifrar por fuerza bruta incluso una frase aleatoria de 6 caracteres llevaría años en una sola máquina, y décadas con GPU convencionales.
- El atacante consigue comprometer por completo el servidor (RCE — ejecución remota de código — durante una sesión activa): podría leer credenciales descifradas de usuarios que estén conectados en ese momento. Pero no obtiene acceso a las credenciales de usuarios guardadas pero sin conexión.
- El atacante obtiene una copia de seguridad de la base de datos de la semana pasada: igual que con acceso de lectura; solo tiene texto cifrado.
Qué significa esto para ti en la práctica
Los tres escenarios anteriores implican niveles de exposición muy distintos en el mundo real:
- Lectura de la base de datos o copia de seguridad robada (el tipo de brecha más común): el atacante obtiene bloques cifrados y nada más. Para usar realmente cualquier credencial guardada tendría que descifrar por fuerza bruta tu frase de contraseña, y scrypt lo hace inviable si es sólida. Tus servidores siguen a salvo.
- Compromiso total del servidor mientras estás conectado activamente (raro y grave): como una sesión SSH abierta necesita tus credenciales reales en memoria, un atacante que controle nuestro proceso en ejecución durante ese intervalo podría extraer las credenciales descifradas de los usuarios conectados en ese momento y usarlas para iniciar sesión en los servidores reales de esos usuarios. Si estás sin conexión en ese momento, tus credenciales guardadas siguen siendo solo texto cifrado para el atacante: no te afecta.
La propiedad clave: incluso en el caso de pesadilla de un compromiso total, el alcance del daño se limita a "quienes estén conectados durante el ataque", no a "todas las personas que hayan usado Server Manager". La mayoría de las brechas catastróficas exponen los secretos de todos los usuarios a la vez; este diseño evita deliberadamente que eso ocurra.
| Tipo de brecha | Qué obtiene el atacante |
|---|---|
| Lectura de la base de datos (lo más común) | Solo texto cifrado — ninguna credencial utilizable |
| Copia de seguridad de la BD robada | Solo texto cifrado |
| RCE completa durante una sesión activa (rara, grave) | Credenciales descifradas de solo los usuarios conectados en ese intervalo |
Esto ofrece una protección significativa frente al patrón de brecha más común (exfiltración de datos), y acepta deliberadamente que un atacante con control total de un servidor en vivo supone una amenaza distinta y más difícil que no afirmamos poder derrotar por completo; aun así, incluso ese peor caso queda limitado a los usuarios conectados en ese momento.
Consejos para elegir una frase de contraseña segura
Todo el esquema de cifrado es tan fuerte como tu frase de contraseña. Recomendamos:
- Al menos 20 caracteres aleatorios, o
- Cinco palabras aleatorias en inglés (al estilo de "correct horse battery staple"): fáciles de recordar, difíciles de descifrar por fuerza bruta
- No reutilices nunca la frase de contraseña que usas para iniciar sesión en tu portátil, tu gestor de contraseñas o tu correo
- No la compartas. Server Manager no la necesita: solo existe entre tú y el bloque cifrado.
Si pierdes la frase de contraseña, las credenciales guardadas no se pueden recuperar. Tendrás que eliminar el perfil de servidor guardado y volver a añadirlo desde cero.
Por qué no ofrecemos acceso a claves "sin contraseña" o "por comodidad"
Algunos productos almacenan claves SSH sin cifrado ("confía en nosotros, las mantenemos seguras") o protegidas solo por la contraseña de la cuenta del usuario. Server Manager no lo hace. El mecanismo de frase de contraseña es la línea que separa "cualquiera con nuestra base de datos puede acceder por SSH a tus servidores" de "cualquiera con nuestra base de datos necesita descifrar primero tu frase de contraseña por fuerza bruta". Creemos que merece la pena la pequeña incomodidad puntual de elegir una frase de contraseña.
Qué NO se envía ni se almacena NUNCA
- Claves privadas SSH en texto claro en nuestra base de datos
- Contraseñas SSH en texto claro en nuestra base de datos
- Tu frase de contraseña de cifrado — en ningún sitio, de ninguna forma
- Credenciales descifradas en ningún almacenamiento persistente — disco, registros, copias de seguridad, caché
El único lugar donde existen credenciales descifradas es la memoria del proceso de la sesión activa, y solo mientras dura esa sesión.
¿Preguntas o dudas?
Si algo de este artículo no queda claro, o si tienes una pregunta de seguridad específica sobre cómo se gestionan tus credenciales, escríbenos desde Contacto: estaremos encantados de explicarlo con más detalle.