¿Sería seguro este sistema de inicio de sesión RESTful?

3

Por lo tanto, he estado pensando en una forma de crear una API segura y confiable para los inicios de sesión de las aplicaciones.

Esto es lo que mi profesor y yo hemos encontrado:

  1. El Cliente (programa swift) inicializa la conexión con el servidor.
  2. El servidor devuelve un "secreto compartido" (ej. +40) y un hash de un cadena aleatoria de letras y números.
  3. El cliente luego escribe el nombre de usuario y la contraseña (por separado) y lo devuelve con el hash de: hash + "el secreto compartido".
  4. Una vez que el servidor envía datos (paso 2), el servidor hace un hash [hash + "secreto compartido"] y luego lo actualiza en la base de datos
  5. El servidor recibe el valor hash del cliente y lo comprueba la db para ver si coincide
  6. La base de datos también tendrá una marca de tiempo que, si no se actualiza con frecuencia basta con que haya una función que se ejecuta a través de la db y gotas los elementos que ya no se utilizan.
  7. Para cada solicitud después del inicio de sesión, se envía el token de portador.

El token de portador seguirá esta fórmula:
Request verification token = hash [ (original hash) + (shared secret) * (# of requests) ]

¿Es esto suficiente para protegerse contra los ataques de Man in the Middle y la falsificación del cliente, o básicamente algo que podría permitir al atacante hacerse pasar por un usuario?

    
pregunta Reid Pritchard 09.05.2016 - 16:54
fuente

1 respuesta

7

No, está perjudicando activamente la usabilidad sin ningún beneficio para la seguridad.

¡Esto suena como un mal caso de Security Theatre * !

Digo esto porque lo que estás haciendo actualmente es tan seguro como enviar el nombre de usuario y la contraseña a través de HTTPS de todos modos. Todo lo que agrega es un par de comunicaciones adicionales de configuración. Las vulnerabilidades de esta implementación, así como las vulnerabilidades del envío de contraseña y nombre de usuario de HTTPS son exactamente iguales .

Vamos a desglosar el ejemplo:

Configuración y uso del secreto

  1. Establecer conexión segura
  2. Enviar carga útil para ser almacenada
  3. Confirme la carga útil y, si se confirma, inicie sesión

Configuración y uso de una contraseña

  1. Establecer conexión segura
  2. Enviar carga útil para ser almacenada
  3. Confirme la carga útil y, si se confirma, inicie sesión

Estos pasos son exactamente iguales y no ofrecen seguridad adicional. Si se produce una toma de control completa (MITM / nivel de sistema), lo mismo que sucedería con un nombre de usuario y una contraseña ocurrirá en su sistema. El atacante seguirá viendo todos los datos a medida que se transfieren y acceden entre su sistema y el servidor. Es por eso que las adquisiciones completas son tan peligrosas. Básicamente, no hay nada que pueda hacer para proteger al usuario. El usuario está utilizando un sistema de comunicación que ya no es el suyo, pero los atacantes y ese atacante pueden ver y usar todo lo que hay en la comunicación.

Realmente todo lo que estás haciendo es generar un secreto (comúnmente llamado contraseña) para almacenar, y algunos metadatos (comúnmente llamado nombre de usuario) para identificarlo. Si los metadatos y el secreto coinciden con una entrada, recupera esa información. La única ventaja que está obteniendo es que el usuario obtiene una contraseña extra larga. ¿Pero a qué fin? Bcrypt tiene una longitud máxima de caracteres, por lo que está limitando el número de caracteres que puede tener una contraseña individual. Ahora también tiene ese secreto compartido para preocuparse de obtener lo mismo cada vez o de su usuario o nunca podrán iniciar sesión.

Las contraseñas y los nombres de usuario sobre HTTPS se han usado con tanta frecuencia porque después de cierto punto (la conexión HTTPS) no hay nada que pueda hacer para aumentar la seguridad. Si alguien tiene acceso a todas las comunicaciones, o al espacio de la memoria, todas sus técnicas acaban de ser vencidas, ya que solo tienen que recrear sus pasos y es posible que nunca lo sepan hasta que ejecuten su ataque.

*: A partir de la semana pasada, esta frase ahora se macro en mi teclado ...
*: ¡El teatro de seguridad es el acto de poner en práctica prácticas que no hacen nada para mejorar la seguridad, y realmente pueden dañarlo!

    
respondido por el Robert Mennell 10.05.2016 - 00:08
fuente

Lea otras preguntas en las etiquetas