¿La lista de "Prohibición de contraseñas" de Microsoft almacena de forma insegura las contraseñas de los usuarios?

En Microsoft, estamos prohibiendo las contraseñas más utilizadas en los ataques y variantes cercanas. No estamos basando esto en nuestra población de usuarios, quienes (debido al sistema) no comparten estas contraseñas a menos que los ataques cambien.

Las listas de ataques generalmente se derivan de estudiar infracciones. Los atacantes son lo suficientemente inteligentes como para mirar listas para descubrir contraseñas de alta probabilidad, luego hacer su fuerza bruta, etc. en torno a esas palabras de alta frecuencia. Miramos las mismas listas más los patrones de ataque para determinar nuestras listas de prohibición.

Espero que esto ayude.

Un sistema que verifica las contraseñas de cuentas existentes antes de decidir bloquear la contraseña de un nuevo usuario como "demasiado común" sería, de hecho, contraproducente. No solo le haría saber a un usuario o atacante que, de hecho, la contraseña es válida para algunas cuentas, sino que es válida para un lote de cuentas. Específicamente, el valor umbral de puntos en común - 1 de ellos.

Por lo tanto, el enfoque descrito en el artículo es, de hecho, el enfoque que Microsoft utiliza para prohibir las contraseñas comunes para las cuentas de Microsoft y Azure AD. Es una combinación de contraseñas comunes y / o débiles conocidas, contraseñas que se usan comúnmente en intentos de acceso por fuerza bruta y variaciones en aquellas contraseñas que se consideran demasiado similares.

  

¿Se podría construir un sistema seguro que verifique las actualizaciones de contraseñas?   contraseñas de otras personas y las rechazó si una contraseña era demasiado   común?

Hay razones para no hacerlo, pero si me pidieran que evitara el uso excesivo de las contraseñas, recibiría la contraseña, la Hash, almacenaría el hash en una tabla sin conexión con ningún usuario ni siquiera el texto que se usó para crear el hash, o actualizar el conteo si ya existe. Si el conteo excede algún límite, aconseje al usuario que elija otra contraseña. Una vez que se proporcione una contraseña aceptable, sáltela y almacene el hash salado para el usuario.

Por lo tanto, no estás comparando las contraseñas de otros usuarios directamente, solo contra sus hash sin sal.

Creo que lo mejor es verificar la debilidad de la contraseña en el lado del servidor, esto puede ser una operación costosa (en la búsqueda de ejemplos en los diccionarios). También las contraseñas comúnmente utilizadas o verificadas para ataques son una buena apuesta.

Es posible que MS primero intente hacer hash de la contraseña y compararla con una lista de contraseñas no seguras (que en realidad no son utilizadas por ningún usuario real). Si el hash falla, entonces, en el ejemplo, podría intentar buscar la fuerza de la contraseña con otro eurista , finalmente puede rechazar o aceptar la contraseña y olvidarse de ella en su versión sin hash. Si se rechaza la contraseña, es probable que se haya agregado a la lista hash no segura .

La verificación de la debilidad de la contraseña también puede tener en cuenta los ataques comunes utilizados, por lo que tiene que ser un algoritmo en evolución.

Esto tiene 2 ventajas:

1. No es necesario que almacene TODOS los hashes de contraseñas no seguras.
2. Puede prohibir colisiones altogheter en hashes (por ejemplo, una contraseña segura con el mismo hash de una contraseña débil).

Por supuesto, esas son solo especulaciones, no podemos conocer las medidas de seguridad de contraseña tomadas por un cuerpo tan grande como Microsoft.

Como medida final, solo usaría un hash diferente para las contraseñas débiles en comparación con las contraseñas reales de los usuarios.

EDITAR: ¿Por qué incluso las contraseñas débiles deberían estar ocultas? Para mí no hay necesidad de un hash fuerte, pero las contraseñas débiles de hashing permitirían al menos "asegurar" datos valiosos. No tiene ningún costo hacer un hashing simple, pero si se produce una fuga de datos en la base de datos, sabrá que al menos los competidores no podrán revertir fácilmente las contraseñas débiles, que aún puede ser un problema de seguridad para los servicios que no utilizan la prohibición lista o al menos puede causar una pequeña ventaja económica .

Entonces, para responder al comentario de GroundZero: No, para mí ni las contraseñas débiles deben almacenarse en texto sin formato. Un simple hachís beneficiaría a la corporación de todos modos. Esto se debe a que hay contraseñas que son específicas de la cultura, recopilar esa información requeriría una inversión masiva, ¿por qué debería almacenar información valiosa de una manera fácil de recuperar?