He buscado temas relacionados, pero he encontrado otros existente answers No ser satisfactorios, ya que requieren la instalación de herramientas especiales.
Este es un caso de uso muy común. Por ejemplo, quiero compartir credenciales de inicio de sesión confidenciales con otros miembros de mi equipo para que podamos administrar servidores.
El texto simple debe estar cifrado, y luego la contraseña y el texto cifrado deben transferirse a la parte amiga a través del canal inseguro que es Internet.
¿La captura? No quiero tener que guiar a mi asociado a través de (o sobrecargarme por tener que pasar) instalando PGP o generando un par de claves RSA de 2048 bits y alojando un servidor SFTP o algo así.
Eso significa que la única opción que queda es el navegador web.
Aquí está mi solución hasta ahora. Considere onetimesecret.com como un servicio generalizado accesible en la web que realmente hace lo que promete hacer. Mi pregunta es, ¿se puede mejorar aún más?
- Alice ejecuta
cat /dev/urandom | base64, toma parte de la secuencia, lo suficientemente larga como para ser una buena contraseña, y no es demasiado larga para el siguiente paso - Alice envía esta cadena a Bob a través de enlace
- Alice espera a que Bob informe que la cadena se ha recuperado correctamente. Si confiamos en
onetimesecret.com, esto significa que solo Alice y Bob están en posesión de la cadena. Si Bob informa que el enlace está muerto y se ha accedido, Alice tira y genera una nueva contraseña. - Alice cifra el texto sin formato con la contraseña que Bob ha recibido correctamente. Por ejemplo, el cifrado AES utilizando un archivo 7z o RAR.
- Alice envía a Bob otro enlace enlace con el contenido. Hay un pequeño defecto aquí, que es que el servicio
onetimesecret.comno parece admitir archivos adjuntos. Una solución puede ser codificar en Base64 la carga útil cifrada y enviarla. O, lo que es menos deseable, Alice puede simplemente enviarlo por correo electrónico: en este caso, un adversario puede obtener una copia del archivo cifrado, pero aún así tendrá que descifrarlo. El paso 1 se encarga de hacer esto lo suficientemente difícil.
El enlace más débil en esto es probable que sea el paso # 3. Creo que la terminología correcta aquí es "Autenticación".
Las opciones del adversario son, por lo que puedo decir,
- ser
onetimesecret.como tener acceso interno a él (lo hacemos con la mano y decimos que está bien, están seguros) - rompe TLS o HTTPS. (También lo hacemos a mano y decimos que está bien, nuestro sistema operativo está parcheado, nuestro navegador está parcheado)
- suplantar a Bob hasta que Alice realice el paso 5. (Alice exige que Bob permanezca en el teléfono para verificar el paso 3)
Y podría estar indicando lo obvio aquí, pero solo para aclarar, la necesidad de estos 5 pasos es agregar un tipo de paso de "manual" de forma independiente, en un esfuerzo por evitar la fuga de datos. Esto todavía significa que tenemos confiar en el servicio web onetimesecret.com para destruir realmente los mensajes que le enviamos que promete que se entregan una sola vez.
El tercer elemento de la segunda lista es el que corresponde a la parte de autenticación de nuestro saludo personalizado. La autenticación segura tradicional / estándar no es posible sin la participación de pasos adicionales para generar claves seguras. Estoy tratando de racionalizar las cosas hasta el punto en que se vuelvan prácticas. Lo que significa que no es necesario que los usuarios generen claves.