¿Cuál es el valor de seguridad de este registro de usuario de SRP sobre la marcha?

3

Actualmente estoy implementando SRP en un juego que estoy desarrollando. Sin embargo, distribuiré este servidor de juegos y este cliente, por lo que me gustaría que el registro se permita sobre la marcha, sin requerir que el anfitrión use algún tipo de foro o comunicación por correo electrónico para preinscribir la cuenta antes del primer inicio de sesión. Repasaré el flujo básico de SRP y luego mi registro cambiará.

Documentación SRP: Encontrado aquí

  1. El usuario ingresa su nombre de usuario y contraseña en el cliente.
  2. El cliente envía el nombre de usuario y un valor generado aleatoriamente al servidor.
  3. El servidor obtiene el verificador de sal y contraseña (que es el resultado de una función en la contraseña, ambas almacenadas externamente) del usuario y envía el valor de sal y otro generado aleatoriamente al cliente.
  4. Cada lado ahora, de forma independiente, calcula una clave de sesión compartida sólida, y prueba esa clave entre sí.
  5. Si ambas pruebas coinciden, el usuario se ha autenticado correctamente.

Para agregar la funcionalidad de registro, aquí están mis cambios propuestos.

  1. El usuario ingresa su nombre de usuario y contraseña en el cliente.
  2. El cliente envía el nombre de usuario al servidor.
  3. El servidor comprueba si existe actualmente un usuario con el nombre de usuario enviado por el cliente.
  4. Si no existe ningún usuario, el servidor envía la clave pública RSA al cliente, solicitando al cliente que genere un salt y un verificador.
  5. El cliente envía la sal, el valor efímero público y el verificador al servidor, y lo codifica con la clave pública.
  6. El servidor decodifica el salt y el verificador con la clave privada.
  7. Cada lado ahora, de forma independiente, calcula una clave de sesión compartida sólida, y prueba esa clave entre sí.
  8. Si ambas pruebas coinciden, el usuario se ha autenticado correctamente.
  9. Si el usuario se ha autenticado correctamente, la sal y el verificador se guardan en la base de datos o archivo para el usuario.

¿Sería esta una forma aceptable y segura de registro en vuelo? ¿O hay algunas cosas que no he considerado?

Editar: Parece que no he proporcionado toda la información necesaria. La forma en la que estoy modelando mi juego es similar a los servidores de Minecraft, donde los usuarios pueden descargar el cliente y conectarse a cualquier número de servidores disponibles alojados por el usuario, o ellos mismos pueden hospedar el servidor. Sin embargo, la diferencia es que las cuentas de usuario de Minecraft se crean una vez, cuando se registran para la cuenta y cuando inician el cliente, el cliente se autentica con los servidores oficiales de Minecraft. Quiero dejar la administración de la base de usuarios a la gente que hospeda los servidores; de esa manera, las únicas cuentas de usuario que conocen, son las que se han registrado en su servidor.

    
pregunta Zymus 28.12.2014 - 02:37
fuente

3 respuestas

3

Sí, su enfoque funcionaría.

Aunque algunos comentarios.

Donde dices:

  
  1. El cliente envía el nombre de usuario y un valor generado aleatoriamente al servidor.
  2.   

No está claro cuál es el propósito del valor aleatorio y no creo que sea necesario.

Después dices:

  
  1. Si no existe ningún usuario, el servidor envía la clave pública RSA al cliente, solicitando al cliente que genere un salt y un verificador.
  2.   

SRP está diseñado de tal manera que se le brinde sal a cualquiera que conozca el nombre de usuario que desea realizar una prueba de contraseña. Puede ser un atacante hostil que intenta adivinar la contraseña que ha aprendido el nombre de usuario. Así que realmente cifrar la sal en el registro no agrega seguridad. Es necesario cifrar el verificador para evitar un ataque de diccionario sin conexión. La sal que puede enviar junto con el nombre de usuario en el paso 2.

Para mayor seguridad, vale la pena cifrar el nombre de usuario en el cable; un atacante necesita saber eso para tratar de adivinar contraseñas obvias o muy débiles. Por lo tanto, es mejor utilizar TLS para cifrar toda la comunicación de registro de extremo a extremo para proteger la identidad del usuario. Su enfoque necesita una clave pública RSA para cifrar (al menos) el verificador. Eso implica generar un par de claves privadas públicas para el servidor. Por lo tanto, es un esfuerzo equivalente generar un certificado autofirmado para cada servidor luego de la instalación. Luego, puede ejecutar TLS durante todo el proceso de registro con el certificado autofirmado generado.

Si solo va a encriptar el verificador, debe obligar al usuario a seleccionar una contraseña segura para protegerse contra alguien que vio el nombre de usuario de texto sin formato que adivina una contraseña débil. Incluso si encripta el nombre de usuario, las personas generalmente usan el mismo nombre de usuario en muchos servicios, por lo que es fácil de adivinar; Por lo tanto, imponer una contraseña segura sigue siendo una buena idea.

(Edit vea esta respuesta / pregunta que también sugiere que una conexión encriptada es el camino a seguir enlace )

( Editar tenga en cuenta que proteger el nombre de usuario es una buena idea que debería considerar usar TLS para iniciar sesión en el juego. Emita un número aleatorio de 128 bits como token de sesión y pídales que se desconecten y vuelvan a conectar sin cifrado. pasando el token de la sesión como su credencial para asignar la nueva conexión no cifrada a la cuenta de usuario a la que emitió el token a través de TLS. Entonces, nunca tienen que pasar su nombre de usuario en texto simple).

    
respondido por el simbo1905 09.01.2015 - 00:50
fuente
2

Una cosa a considerar es bots. Has hecho el registro muy fácil y conveniente. Eso también hace que sea muy fácil y conveniente para los que sufren, los tramposos u otros tipos de malhechores crear bots que inundan un servidor.

Dependiendo de cuál sea tu juego, eso podría ser irrelevante. Pero el registro automatizado sin CAPTCHA es algo que debe considerar.

    
respondido por el Steve Sether 05.01.2015 - 19:55
fuente
1

El segundo problema más grande que veo con el registro es que no hay autenticación del servidor. Cuando me estoy registrando inicialmente, no hay forma de verificar que estoy hablando con el servidor real, y no con uno falso. No parece que un atacante pueda interceptar tráfico con un intermediario (no pueden aprender rápidamente a hacerme pasar por el servidor, por lo que lo mejor que pueden hacer es transmitir mi sal y verificador y abandono). Sin embargo, tan pronto como el atacante supiera mi verificador, podrían comenzar a realizar un ataque de diccionario contra él, como si hubieran obtenido un hash de contraseña. Desafortunadamente, SRP no está especialmente diseñado para resistir ataques de diccionario contra los verificadores; una implementación común utiliza solo dos iteraciones de SHA-1 y una exponenciación modular. Incluso si lo hizo usó un buen hash de contraseña, el hecho de que una contraseña esté fuertemente marcada con un buen salt no significa que esté bien que un atacante obtenga el hash, y que un atacante probablemente todavía estará capaz de forzar contraseñas débiles de fuerza bruta. Si el atacante hace esto con éxito, ahora tiene un combo de nombre de usuario y contraseña que tiene una buena oportunidad de trabajar en otros sitios web más importantes.

La única forma de prevenir ese ataque implicaría algún tipo de comunicación fuera de banda. Por ejemplo, TLS normalmente lo resuelve con la PKI basada en X.509 (que es lo que protege el registro en un sitio web de HTTPS).

El problema más importante primero es que el desarrollo de juegos no suele ser el lugar para diseñar un nuevo sistema de autenticación, porque la seguridad es difícil . Es mucho, mucho mejor si se adhiere a los protocolos estándar. Además, hacer esto requerirá la implementación de SRP, y es también mejor atenerse a las implementaciones estándar. Por lo tanto, la mejor manera de hacerlo sería usar una buena implementación de SRP, ya que está diseñada para ser utilizada, y usar otra cosa para el registro (como TLS o algo así, donde puede aceptar certificados de CA estándar y permitir autofirmas pero avisar al usuario).

    
respondido por el cpast 05.01.2015 - 07:03
fuente

Lea otras preguntas en las etiquetas