¿Es posible la autenticación segura fuera de línea de la aplicación web?

5

Actualmente estoy pensando en una aplicación web que pueda desconectarse (después de estar en línea) y aún así poder proporcionar autenticación al usuario de forma segura. (Por ejemplo, en un entorno multiusuario, es muy importante evitar el acceso de otros usuarios).

En este momento, estaba considerando una autenticación de hash de contraseña con algo de sal, y acabo de ver esta pregunta SO: enlace

Pero como este es un entorno web, debo asumir que los demás tienen acceso al código fuente de la aplicación y, por lo tanto, la sal se filtra. (Además, el atacante podría usar el hash para imponer la contraseña).

Entonces ... para resumir, mis 2 preguntas son:

  1. ¿Es efectiva la salazón incluso cuando se filtra? Supongo que no a la pregunta, ya que se necesita O (X ^ (m + n)) para forzar lo desconocido ...  y empeora cuando el atacante usa el hash de la contraseña para aplicar fuerza bruta al passwwd ..
  2. ¿Hay alguna forma efectiva (segura) de autenticar al usuario?
  3. Cualquier buena manera de generar una clave DES para cifrar los datos del usuario  (¿Y proporciona una forma para que el servidor distinga entre datos manipulados y datos reales?)
pregunta user7832 30.07.2013 - 11:18
fuente

2 respuestas

2

Responderé a tus "2" preguntas a continuación:

  1. En cuanto a la sal: se supone que una sal es pública. Algunas veces se usa un valor secreto adicional (por ejemplo, antes de la contraseña pendiente). Esto a menudo se conoce como "pimienta".

  2. Pruebe TLS con autenticación de cliente. Utilice las credenciales dentro del certificado del cliente (después de la autenticación exitosa y el establecimiento de la sesión) para proporcionar control de acceso.

  3. Sí, es posible derivar una clave DES "de buena manera"; use PBKDF2 con un alto recuento de iteraciones y gran cantidad de sal aleatoria. Sin embargo, la clave DES ya no es segura una vez que se usa para el cifrado debido a ataques de fuerza bruta.

respondido por el Maarten Bodewes 30.07.2013 - 14:17
fuente
2

Respuesta genérica: si la autenticación basada en contraseña se puede realizar fuera de línea, entonces la aplicación necesariamente contiene todo lo necesario para decidir si una contraseña determinada es la correcta o no. Esto implica inevitablemente que al descargar el código completo de la aplicación y el contenido, el atacante puede "emular" el servidor sin conexión en su propia máquina y probar las contraseñas en su tiempo libre, limitado solo por el poder de cómputo que puede reunir (cuántas PC comprará o renta) y el costo computacional inherente de verificar cada contraseña. Esto se conoce como una situación de diccionario sin conexión .

En el mejor de los casos , en tal caso, puede aumentar el costo utilizando el hash lento (muchas iteraciones de una función de hash subyacente, o algo similar) y sales (para evitar ataques paralelos, costos compartidos , tablas precomputadas ...). Consulte esta respuesta para un tratamiento completo.

Los ataques de diccionario sin conexión son una preocupación. Estar en tal situación no es cómodo. Si los usuarios aceptan una espera de 1 segundo para la autenticación en su teléfono inteligente, entonces la CPU del teléfono inteligente debe necesariamente poder verificar una contraseña dentro de un segundo. Un atacante con algunas PC buenas podrá "intentar" al menos unas docenas de contraseñas por segundo; haga que unos pocos cientos, si el algoritmo hash se asigna bien a lo que puede hacer la GPU, unos cuantos miles es que el atacante es laborioso y fue directo a algunos FPGA implementación. Además, el atacante suele ser paciente y puede permitirse esperar una o dos semanas antes de obtener una contraseña de usuario. Esto se suma, muy aproximadamente, a mil millones de intentos de contraseña para el atacante.

Capacitar a los usuarios promedio para elegir contraseñas que resistan un ataque de fuerza bruta de mil millones de contraseñas potenciales, es difícil. Consulte esta pregunta para una discusión sobre el tema. Por otro lado, si usted elige la contraseña (no el usuario), seleccione una secuencia de 15 letras aleatorias: eso es 70 bits de entropía, y esto resistirá el tiempo suficiente para disuadir a los atacantes ( un espacio de contraseña de tamaño 2 70 es enorme ).

Tenga en cuenta que las sales no deben ser secretas, y son efectivas incluso cuando son conocidas por el atacante. Una sal secreta no es una sal, sino una clave . No puede tener eso en su situación: uno debe suponer que el atacante volcó y realizó la ingeniería inversa del código completo de la aplicación. En gran medida, su contexto es similar al del cifrado basado en contraseña: protege la confidencialidad de un dato, con respecto a una contraseña secreta, sin hardware específico.

    
respondido por el Thomas Pornin 31.07.2013 - 18:49
fuente

Lea otras preguntas en las etiquetas