¿Cómo implementar contraseñas específicas de la aplicación usando hashes fuertes?

3

Estoy implementando un servicio donde las contraseñas específicas de la aplicación parecen una buena opción para mejorar la seguridad. Una pregunta sobre por qué y cuándo podrían tener sentido ya se ha discutido aquí Cuenta de Google: implicaciones del uso de contraseñas específicas de la aplicación

Ahora, estoy interesado en cómo, especialmente con hashes fuertes como bcrypt o scrypt.

  • Supongo que Google, iCloud & Co almacena los hashes de las contraseñas específicas de la aplicación.
  • Dado que todas las contraseñas específicas de la aplicación se asignan al mismo nombre de usuario, ¿eso significa que uno tiene que comparar el hash de la contraseña dada con todos los hashes conocidos del nombre de usuario dado?
  • Si es así, y digo que uso un algoritmo de cifrado como bcrypt o scrypt con maxtime entre 100 y 200 milisegundos, ¿no tendría que paralelizar el hashing y amp; ¿Comparación para minimizar el tiempo de espera en el peor de los casos?
  • ¿Hay alguna buena razón por la que decidieron no usar nombres de usuario específicos de la aplicación? p.ej. por ejemplo, tengo una cuenta "foo" y ":" no está permitido en un nombre de usuario, ¿por qué no usar "foo: bar" como el nombre de usuario específico de la barra de aplicaciones de la cuenta "foo"? De esa manera, la relación nombre de usuario < - > La contraseña es 1: 1 de nuevo. ¿Es porque los usuarios no deberían tener que recordar nombres múltiples?

Muchas gracias por tus pensamientos.

    
pregunta RobS 08.04.2015 - 07:05
fuente

1 respuesta

1

No implementé tal sistema.
Pero todavía puedo responder a sus preguntas (espero).

Una contraseña diferente para cada aplicación es una buena característica para mejorar la seguridad, por lo que una contraseña dañada no le dará acceso inmediato a todas las aplicaciones.

El problema con el inicio de sesión con una contraseña diferente para cada aplicación es la cantidad de contraseñas. Google tiene como 10 aplicaciones, por lo que tendría que recordar 10 contraseñas diferentes (buenas), lo cual es bastante improbable para un usuario estándar, que solo usaría una y la misma para todos los servicios (incluso puede ser una mala). Sin un administrador de contraseñas, es imposible superar esta carga y la gente comenzará a quejarse porque dicen: "Oye, ¿me registré una vez, ¿no es suficiente?"

Técnicamente no hay (casi) ninguna diferencia en la velocidad entre varias contraseñas y una sola contraseña. Si implementara un sistema de este tipo, utilizaría el segundo enfoque que mencionó, así que marque un nombre de usuario con la aplicación que está usando (tal vez no en la cadena, ya que esto puede causar algunos ataques graves, pero con algunos datos asociados) . Así que el usuario inicia sesión, proporciona su contraseña, abre la base de datos de contraseñas de su aplicación, busca el nombre, realiza el hash de la contraseña y compara la etiqueta calculada con la etiqueta almacenada. Si coinciden, concede acceso, si no, se niega el acceso.

Si estuviera almacenando un grupo de etiquetas con el mismo nombre de usuario (lo que sería estúpido, ya que permitiría al usuario usar varias contraseñas para la misma cuenta y, por lo tanto, limitar la fortaleza a la fuerza de la peor contraseña), Simplemente calcule la etiqueta una vez (suponiendo que haya usado la misma sal) y busque coincidencias. Si era inteligente, ha usado diferentes sales y, por lo tanto, ha introducido una penalización de rendimiento severa. (el tiempo de inicio de sesión en el peor de los casos se vuelve lineal con el número de cuentas), a menos que se pueda paralizar, lo que podría ralentizar el inicio de sesión de otros usuarios, ya que tienen que esperar el tiempo de CPU que necesitan para iniciar sesión.

    
respondido por el SEJPM 08.04.2015 - 14:53
fuente

Lea otras preguntas en las etiquetas