¿Algún problema con este diseño de seguridad para almacenamiento en la nube? El servidor ni siquiera necesita saber la contraseña para iniciar sesión en alguien

Question

¿Algún problema con este diseño de seguridad para almacenamiento en la nube? El servidor ni siquiera necesita saber la contraseña para iniciar sesión en alguien

#1 de Tom Leek (2 votos)

0

He creado un algoritmo que creo que voy a usar para un servicio de almacenamiento en la nube que estoy desarrollando, si no hay problemas o vulnerabilidades con él. Es esto junto con TLS y el secreto hacia adelante implementado. Además, al iniciar sesión en un nuevo dispositivo, debe confirmarlo a través de su cuenta de correo electrónico.

Para crear una cuenta:

Genere dos claves aleatorias, la clave A y la clave B. La clave A se usa para probar la identidad de quién se está firmando. La clave B se utiliza para cifrar sus archivos con AES-256.
Cifre las dos claves con AES-256 usando un hash de la contraseña del usuario. Pronto publicaré una pregunta por separado sobre la creación intencional de un retraso en la función de hash, para evitar ataques de fuerza bruta.
Envíe las claves cifradas al servidor, junto con un hash SHA-256 de la Clave A.

Para iniciar sesión:

Descargue las claves cifradas del servidor.
Descifra las claves con la contraseña hash.
Suba la clave A al servidor.
El servidor hash Key A y lo compara con el hash almacenado. Si los dos son idénticos, notifique al cliente que la contraseña es correcta (no que se haya enviado).
Elimine la copia de la Clave A en la memoria del servidor.

Para hacer cambios a los archivos:

Inicie sesión siguiendo los pasos que se muestran arriba. El servidor rechazará cualquier acción a menos que haya iniciado sesión, obviamente.
Cifre todos los archivos con AES-256 usando la Clave B (almacenada en la memoria del cliente, nunca guardada en texto plano en el servidor) antes de enviar en línea. Descifra todos los archivos sin conexión en consecuencia.

Para cambiar la contraseña:

Inicia sesión siguiendo los pasos anteriores.
Encripta la clave A y la clave B (almacenadas en la memoria después de iniciar sesión) con el hash de la nueva contraseña.
Indique al servidor que elimine las claves cifradas y cargue las nuevas.

Para restablecer la contraseña y las claves (en caso de incumplimiento):

Inicie sesión. Si no puede hacerlo con la contraseña y los pasos anteriores porque se cambió su contraseña, use una unidad de recuperación (creada opcionalmente al configurar una nueva cuenta) con las claves almacenadas en ella.
Descargue todos los archivos del servidor.
Descifre los archivos con la clave B.
Genere dos nuevas claves aleatorias, luego encripte las nuevas claves con la nueva contraseña y cárguelas, junto con un hash de la nueva Clave A.
El servidor almacena en caché las claves cifradas y el hash, y envía un correo electrónico de confirmación para restablecer la contraseña y las claves de la cuenta.
Una vez que se acepta el correo electrónico de confirmación, el cliente comienza a cifrar los archivos con la nueva clave B y a cargarlos al servidor. Una vez que todos los archivos se transfieren completamente, el servidor elimina los archivos antiguos.
Todas las claves se invalidan, al cerrar sesión en la cuenta en todos los demás dispositivos.

Por favor, avíseme si hay algún problema con este algoritmo o mejoras que podría hacer.

cryptography encryption cloud-computing

pregunta Phoenix Logan 27.12.2013 - 19:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption cloud-computing

¿Cuál es la cantidad total de información sobre mi computadora que puede obtener un sitio web? funciona una clave pública con todos los programas encriptados

score 2 · Answer 1

El punto difícil en todos estos protocolos basados en contraseñas es la prevención de ataques de diccionario sin conexión . Un ataque de diccionario es cuando el atacante intenta contraseñas potenciales; está sin conexión si el atacante puede hacerlo en casa sin interactuar con el servidor original o el usuario objetivo. Los ataques de diccionario fuera de línea tienden a funcionar bien, porque los usuarios son usuarios humanos , y por lo tanto, en promedio, sus contraseñas se consumen mucho. El hashing lento y salado (consulte esta respuesta ) puede ayudar hasta cierto punto, pero en última instancia no solucionará el problema. Las contraseñas son débiles.

Es inevitable que haya suficiente en el servidor para ejecutar un ataque de diccionario sin conexión. De hecho, si el atacante obtiene una copia completa del contenido del servidor, puede emular el servidor en sus propias máquinas. El servidor en ejecución debe indicar de alguna manera si a un cliente entrante, armado solo con su contraseña, se le debe permitir operaciones destructivas en los archivos o no; por lo tanto, el servidor debe poder distinguir entre una contraseña correcta y una incorrecta. Un atacante que emula el servidor y el cliente puede "probar contraseñas" y eso es, por definición, un ataque de diccionario sin conexión.

El problema, entonces, es asegurarse de que solo el servidor tenga este poder; que los valores que permiten ataques de diccionario sin conexión no se distribuyen innecesariamente al público en general. Por lo tanto, en su propuesta, hay áreas vulnerables . En particular:

La "clave A y B cifradas con la contraseña" puede permitir ejecutar un ataque de diccionario sin conexión. Dado que este blob se obtiene del servidor antes del inicio de sesión real, cualquiera puede tenerlo, incluido el atacante. El formato de encriptación debe ser bastante especial para evitar que se abuse de él (una descripción del hecho es que el descifrado con la contraseña incorrecta todavía debe parecer que funciona). Los formatos de cifrado habituales serán débiles .
Del mismo modo, hay archivos almacenados, encriptados con la clave B. Un atacante con las "claves encriptadas con la contraseña" blob y un archivo encriptado puede usar eso para probar posibles contraseñas ( pruebe las contraseñas hasta que el descifrado del archivo produzca algo que "tenga sentido"). Esto implica que los archivos cifrados no se deben mostrar a nadie, excepto al usuario legítimamente autenticado (necesita la autenticación del usuario para el acceso de lectura, pero también para el acceso de escritura).

Sería más genérico y menos confuso separar las dos teclas A y B: realmente son tipos distintos de objetos y se utilizan de diferentes maneras. Lo que realmente quieres es lo siguiente:

Un método de autenticación basado en contraseña, en el que el servidor no aprende la contraseña del usuario, pero puede verificarla.
Un almacenamiento para archivos con cifrado basado en contraseña. Este almacenamiento utilizará un sistema de cifrado de dos pasos: una clave simétrica K se cifra con la contraseña, y todos los demás archivos se cifran con K (esto acelera los cambios de contraseña) .

Tenga en cuenta que la parte sobre no aprender la contraseña del usuario realmente es: no aprender la que se utiliza para cifrar realmente los archivos. El método genérico sería el siguiente: para una contraseña de usuario determinada P , calcule f (P) con una función de hashing de contraseña adecuada f ( por ejemplo, bcrypt o PBKDF2). Extienda el resultado con una Función de derivación de claves en dos claves U y V (PBKDF2 incluye su propio KDF; de lo contrario, un KDF barato puede ser una simple invocación de una función hash como SHA-256 si el tamaño de salida es lo suficientemente grande como para dividirse en U y V ). El servidor almacena h (U) para alguna función hash h , y V se utiliza para cifrar la clave simétrica K .

Con este sistema, el servidor aprende U pero esto no le da ninguna pista sobre V , mediante la aplicación de las virtudes del KDF (un KDF es, en su mayoría, un función hash con un tamaño de salida configurable). Además, U aún se encuentra después de la función f () , por lo que U solo permite un lento ataque de diccionario sin conexión, algo que el servidor ya podría han hecho.

Este sistema requiere que cualquier usuario pueda obtener su sal antes de la autenticación. Esto no es un problema, ya que esta sal es solo un valor aleatorio. Observe cómo este protocolo alternativo elimina la necesidad de un "sistema de cifrado especial" que no permita un ataque de diccionario sin conexión.

Para puntos de brownie adicionales, use U como la contraseña para TLS-SRP. Esto asegurará la autenticación mutua entre el cliente y el servidor, según la contraseña, sin necesidad de ningún certificado.