El servidor verifica la contraseña del cliente sin tener que poseerla

Question

El servidor verifica la contraseña del cliente sin tener que poseerla

#1 de Michael (3 votos)
#2 de AbsoluteƵERØ (2 votos)

4

tl; dr: Me pregunto cuál es la mejor manera de verificar una contraseña cuando el cliente no confía en el servidor.

Sé de dos maneras comunes en que los servidores pueden verificar si la contraseña de un usuario es correcta:

El servidor almacena el hash de la contraseña, el cliente envía la contraseña y el servidor hace un hash de la contraseña y compara el hash con el hash almacenado. Si coinciden, la contraseña es correcta.
El servidor almacena la contraseña en texto sin formato y genera un salt que combina con la contraseña y los hashes, y luego envía el salt al cliente. El cliente hash la contraseña y el salt, y envía ese hash de vuelta. El servidor compara los dos hashes y, si coinciden, la contraseña es correcta.

Sin embargo, ambos métodos requieren que el cliente confíe en el servidor, y el primero requiere que la conexión sea segura (mientras que el segundo obviamente no lo hace).

He pensado en una forma, pero no sé si es buena porque no tengo experiencia en criptografía, no sé qué contorsiones pueden comprometer la seguridad.

El método es que cuando el cliente crea una cuenta, el cliente genera un par de claves RSA a partir de su contraseña al colocar el generador de números aleatorios con el hash de la contraseña y enviar la clave pública al servidor. Más tarde, cuando el servidor quiera verificar si un usuario tiene la contraseña correcta, puede generar algunos datos y enviarlos al cliente para que los firme. El cliente responde con la firma y el servidor puede verificar la firma, y si es válida, el cliente tenía la contraseña correcta.

De esta manera, el servidor nunca llega a ver la contraseña del cliente.

Esta podría ser una forma estúpida de hacerlo. Sin embargo, me gustaría saber cuál es la forma común de hacer esto, y si no hay una común, lo que los expertos en seguridad aquí piensan de la forma en que lo describí. Como dije, solo conozco de criptografía lo que he aprendido para el desarrollo web, que es ridículo, por lo que podría haber pasado por alto algo obvio.

Información adicional

Sé que solo puede generar un par de claves RSA y almacenar un archivo que contenga la clave en su computadora, como lo que puede hacer para los inicios de sesión de SSH, sin embargo, debe guardar su clave en algún lugar, y si la computadora está incautado entonces su contraseña está comprometida. El método que busco debería requerir solo una contraseña además del nombre de usuario.

passwords validation

pregunta Jecko 11.06.2013 - 20:43

fuente

2 respuestas

2

Uno de los mejores métodos que he visto para algo como esto es Bank of America's SiteKey . La forma en que funciona:

Selecciona una imagen de su base de datos no publicada. (esto se almacena)
Luego les proporciona una descripción personalizada para la imagen. (esto también se almacena)

Esta combinación se llama su SiteKey. Antes de ingresar su contraseña, le muestran el SiteKey para su verificación. Si es lo que ingresó cuando configuró la cuenta, entonces debería poder confiar en el servidor, porque cualquier persona que explote el servidor tendría que tener las imágenes de su biblioteca de imágenes. Su base de datos de usuarios, contraseñas y emparejamientos de SiteKey, y los presenta en un método que parece auténtico.

Si no lo está, no ingresará su contraseña.

Un problema potencial fuera de la implementación bancaria es tan llamativo, que si alguien almacenó su sesión en caché, podrían extraer la imagen y la clave del sitio si se orientaran directamente hacia usted. Probablemente, habrían usado otros bits de su sesión para extraer dinero directamente de su cuenta (o haberlo transferido a otra parte). Sin embargo, tienen precauciones para transferir fondos a cuentas corporativas desde cuentas privadas.

respondido por el AbsoluteƵERØ 11.06.2013 - 22:42

fuente

Lea otras preguntas en las etiquetas passwords validation

¿El estado de la vista cifrada es vulnerable? ¿Proporcionar OAuth para aplicaciones móviles representa una amenaza para la seguridad?

score 3 · Accepted Answer

Algunas variantes de Intercambio de claves autenticadas por contraseña (PAKE) permiten la autenticación mutua con una contraseña; también eche un vistazo a Pruebas de contraseña de conocimiento cero . Aquí el servidor todavía tiene la contraseña del usuario (creada durante la configuración de la cuenta), pero durante el intercambio de claves, el cliente no le da la contraseña al servidor, sino que el cliente y el servidor ejecutan un protocolo que demuestra la posesión de la contraseña y (en el caso de PAKE) establece una clave simétrica compartida.

Las secciones 4.2 y 4.3 del tcpcrypt paper ofrecen una introducción útil a un par de protocolos (aunque se basan en un concepto introducido en el resto de tcpcrypt, a saber, el ID de sesión).

Su método propuesto proporciona la autenticación del cliente al servidor, pero no el servidor al cliente (consulte la PKI de Internet o los protocolos anteriores, que intentan autenticar los servidores también a los clientes). También es vulnerable a la adivinación de contraseñas fuera de línea: dada una única firma de ejemplo sobre los datos del desafío, un atacante puede revisar una lista de contraseñas, generar el par de claves y ver si coincide con la firma del ejemplo.