¿Saber 'a' encriptado con 'b' y 'b' encriptado con 'a' es una posible amenaza?

0

Disculpe por el nombre de la pregunta, pero no pude encontrar ningún otro título adecuado.

Quiero validar la conexión del cliente al servidor. Mi algoritmo se ve así:

  1. Los clientes envían su nombre de usuario: texto simple
  2. El servidor envía un AES entero grande aleatorio cifrado con la contraseña correspondiente al inicio de sesión
  3. El cliente descifra el número usando su contraseña y envía su contraseña cifrada con el mismo número para confirmación
  4. El servidor descifra la contraseña usando el mismo número y verifica si es válida.

Es posible que el intruso pueda saber la contraseña cifrada con un entero y el mismo número cifrado con su contraseña, y aquí está mi pregunta. ¿Es esa una posible amenaza? ¿Es posible encontrar la contraseña o el número?

¿Qué puedo hacer para mejorar esta solución?

    
pregunta Disa 23.12.2013 - 12:16
fuente

4 respuestas

1

Lo que describe es muy similar a la idea detrás de Kerberos, pero no llega a resolver los problemas que Kerberos resuelve.

Saber que tanto AES (A, B) como AES (B, A) sin duda ayudaría a un atacante permitiéndoles probar con autoridad un descifrado válido; si no supieran nada, pero encontraron algunos candidatos para A, B con m1 = AES (A, B), podrían probar que AES (B, A) = m2 donde m2 es el otro mensaje interceptado. Sin embargo, esta es realmente la menor de tus preocupaciones.

Las claves AES tienen que tener una longitud particular. No has mencionado cómo funciona la derivación de tu clave, así que no voy a hablar de eso.

Realmente, el modelo correcto para hacer este tipo de cosas es derivar una clave de la contraseña del usuario en el nodo cliente. El servidor conoce una clave que se puede usar para cifrar los datos de manera que el cliente pueda descifrarlos y, a petición, crea un token de autenticación que envía al solicitante, así cifrado. El token no sirve para nadie que no conozca la clave (privada) del usuario, por lo que es seguro enviarlo a quien sea. Luego el usuario lo descifra y se autentica.

El usuario no necesita enviar inmediatamente este token de vuelta; el servidor puede asumir que quien lo presente está autenticado como el usuario para el que fue emitido.

Ahora, resolveré algunos otros problemas agregando al modelo: la cosa enviada desde el servidor al cliente no es un token, sino otra clave. El usuario, siempre que pueda descifrar la clave, puede usar esa clave para firmar las solicitudes. De esa manera, nada sensible tiene que atravesar la red de forma clara y no hay necesidad de establecer un canal de confianza.

Kerberos lleva esto un paso más allá al permitir que esta clave se use para emitir aún más claves, y tiene algunos otros conceptos, que permiten al usuario iniciar sesión en un lugar para autenticarse en otro. También hay algunos nonces para evitar los ataques de reproducción, y esas cosas. Sin embargo, en la medida en que su solución se desvíe de este modelo, es subóptima.

Lo más destacado aquí es que no desea la contraseña de texto sin formato en ningún lugar, y mucho menos en el servidor, y realmente no necesita enviarla a través de la red o verificarla. Pero, en lugar de rediseñar su sistema para que coincida, solo use uno de los numerosos métodos de autenticación de desafío-respuesta ya implementados, auditados y disponibles.

Los ataques contra su esquema son posibles, pero los ataques en particular dependen de si su token (el gran número al que se refiere) se trata como un nonce, qué tan grande es, cómo obtiene las claves de las contraseñas , cómo trata la contraseña en el servidor, cómo se genera el nonce y algunas otras cosas. La primera línea de ataque que elegiría es predecir el error y usarlo para descifrar la contraseña, validando contra el tráfico en la otra dirección.

    
respondido por el Falcon Momot 24.12.2013 - 22:11
fuente
6

Lamentablemente, lo estás haciendo mal al hacer rodar tu propio esquema de cryptopgrahy.

  

¿Qué puedo hacer para mejorar esta solución?

No ruedes tu propio esquema. Se adhieren a la solución probada para la autenticación. Utilice TLS / SSL para cifrar el tráfico del cliente a su servidor. Utilice un algoritmo de hashing de contraseña seguro como PBKDF2, bcrypt o scrypt para hash la contraseña para el almacenamiento en el servidor.

    
respondido por el Ayrx 23.12.2013 - 12:19
fuente
1

Hay un punto de debilidad en su algoritmo porque se basa en la hipótesis de que el servidor tiene todos los clientes contraseña de texto no cifrado.

Hay un segundo punto de debilidad en su algoritmo en la etapa inicial. Cuando un cliente aún no tiene una contraseña, el servidor no puede enviar un entero aleatorio encriptado con la contraseña del cliente. Esto implica que esta contraseña inicial es conocida previamente compartida , conocida tanto del servidor como del cliente entrante.

Por estas 2 razones (al menos), fue una buena idea haber expuesto tu esquema ...

y no haberlo usado.

    
respondido por el daniel Azuelos 24.12.2013 - 21:09
fuente
1

Aquí, para este escenario puedes usar criptografía asimétrica como RSA .

Ahora, según su problema, si utiliza el mismo número entero para el cifrado y el descifrado, accidentalmente cualquier intruso se enterará, será un problema de seguridad.

Para que puedas mejorar de la siguiente manera.

  1. Los clientes envían su nombre de usuario: texto simple
  2. El servidor crea un par de claves públicas privadas y envía una de las claves al protocolo de intercambio de claves del cliente, y cifrará el mensaje mediante la clave que no comparte y se la enviará al cliente.
  3. A medida que el cliente recibe cualquier mensaje cifrado, será descifrado por la clave que ya le fue enviada por el servidor.
  4. De la misma manera, el cliente encripta el mensaje ya sea generando un nuevo par o utilizando el par existente (nuevo par recomendado) y lo envía al servidor.

El problema es que este escenario es Man-In-Middle Attack , por lo que debe tener implementaciones de seguridad adecuadas para resolver Man-In-Middle Attack que puede leer este artículo.

Pero para resolver su problema principal, debe usar Criptografía asimétrica

    
respondido por el Rohit 03.01.2014 - 10:50
fuente

Lea otras preguntas en las etiquetas