¿Por qué Microsoft no implementa Salt en las contraseñas de los usuarios en Windows?

El manejo de contraseñas en un sistema operativo de Microsoft es complejo porque usan contraseñas para muchos usos. El sistema operativo (o su controlador de dominio) almacenará una versión con hash de la contraseña, pero también hay valores que se cifran simétricamente con claves derivadas de la contraseña o de su hash. Los protocolos de autenticación no incluyen disposiciones para el intercambio de sales cuando debe ocurrir algún hashing del lado del cliente. Es difícil alterar los algoritmos de procesamiento de contraseñas sin afectar a muchos subsistemas y potencialmente romper la compatibilidad con versiones anteriores, que es la fuerza impulsora del ecosistema de Windows.

Se reduce a prioridades estratégicas. Microsoft sabe que modificar el hash de contraseña y los protocolos de autenticación para incluir un salt tendrá algunos costos no despreciables que tendrían que asumir (al arreglar todos los componentes afectados). Por otra parte, no cambiar el hashing de contraseña es más bien "gratuito" para ellos, porque un algoritmo de hashing no convencerá a los clientes de cambiar a otros sistemas que no sean de Microsoft (el mercado de sistemas operativos es, en la práctica, , un mercado cautivo ); se necesita mucho más para forzar a los clientes potenciales a imaginar un cambio de sistema operativo que es muy costoso. Además, el hashing de contraseñas puede calificarse como "defensa en profundidad" , una segunda capa que tiene algún impacto solo una vez que se produjo una infracción; como tal, podría ser presentado como de importancia secundaria. Por lo tanto, es lógico, aunque irritante, que Microsoft no actualice sus malas prácticas de procesamiento de contraseñas.

Históricamente, Microsoft solo realizó una actualización cuando cambió de NTLM v1 a v2, y fue algo necesario porque el hash LM más antiguo era tan débil que estaba empezando a ser vergonzoso . Mi conjetura es que involucró muchos problemas internos y no están ansiosos por volver a hacerlo.

El modelo de sistema de Microsoft es sustancialmente diferente del modelo habitual de 'web' (y, en menor medida, de UNIX). En el mundo de MS, generalmente tiene una cantidad de máquinas bajo su propio control que están estrechamente vinculadas a unas pocas centrales. repositorios y es probable que sepas dónde están la mayor parte del tiempo. (Esto se descompone cuando se trata de IIS; luego, muchas aplicaciones web tienen su propio control de usuario).

Como mencionado en Otra respuesta , los hashes de Microsoft han sido tradicionalmente débiles y probablemente se mantengan así para la compatibilidad con versiones anteriores. Pero tampoco es crítico para su modelo de seguridad: en el modelo de Microsoft, es relativamente trivial cambiar una contraseña. Es relativamente trivial hacer que cambien las contraseñas de todas . También tiene un método robusto para la caducidad de las contraseñas (por lo que cualquier hash perdido perderá rápidamente su valor, definitivamente dentro de 1-2 meses).

También está operando en un mundo donde administradores benévolos escucharon a usuarios no técnicos a través de las trampas de la computación; como solo un ejemplo: no compartir con sal significa que puede hacer que un usuario actualice su contraseña mientras no puede hablar con el controlador de dominio y el controlador de dominio puede resolver el hash de la nueva contraseña simplemente mirando la credencial actual del usuario (usuario + dominio + el nueva contraseña) y su credencial anterior. Esto es un gran beneficio porque significa que la experiencia del usuario (cambiar las contraseñas cada día xxx ) no cambia según el acceso a la red.

Puede que te interese la explicación técnica de Microsoft de su sistema de contraseñas .