Piuttosto semplice - Quindi usiamo le tabelle arcobaleno per ottenere le password degli utenti dagli hash. Quindi, perché Microsoft non implementerà il sale sulle password in Windows come hash(password+salt) ?
Questa implementazione non risparmierà molto dolore, almeno se implementata nel file SAM quando si ha a che fare con il crack delle password degli utenti locali?
La gestione delle password in un sistema operativo Microsoft è complessa perché utilizzano password per molti usi. Il sistema operativo (o il suo controller di dominio) memorizzerà una versione hash della password, ma ci sono anche valori che sono simmetricamente crittografati con chiavi derivate dalla password o dal suo hash. I protocolli di autenticazione non includono le disposizioni per lo scambio di sali quando deve verificarsi qualche hashing sul lato client. È difficile modificare gli algoritmi di elaborazione delle password senza influire su molti sottosistemi e potenzialmente interrompere la compatibilità con le versioni precedenti, che è la la forza trainante dell'ecosistema Windows.
Passa alle priorità strategiche. Microsoft sa che alterare l'hashing delle password e i protocolli di autenticazione per includere un salt avrà alcuni costi non trascurabili che dovrebbero assumere (fissando tutti i componenti che sono quindi interessati). D'altra parte, non cambiare l'hashing della password è piuttosto "gratuito" per loro, perché un algoritmo di hashing flaky non convincerà i clienti a passare ad altri sistemi non Microsoft (il mercato del SO è, in pratica , un mercato vincolato ); ci vuole molto di più per costringere i potenziali clienti a prevedere un interruttore del sistema operativo che è molto costoso. Inoltre, l'hashing della password può essere qualificato come "difesa in profondità" , un secondo strato che ha un impatto solo una volta che si è già verificata una violazione; come tale, potrebbe essere presentato come di secondaria importanza. Pertanto, è logico, se irritante, che Microsoft non aggiorni le sue scarse pratiche di gestione della password.
Storicamente, Microsoft ha fatto solo un aggiornamento, quando è passato da NTLM v1 a v2, ed era abbastanza necessario perché il vecchio hash LM era così debole che stava cominciando a essere imbarazzante . La mia ipotesi è che ha coinvolto un sacco di problemi interni e non sono desiderosi di farlo di nuovo.
Il modello di sistema Microsoft è sostanzialmente diverso dal solito modello "web" (e in misura minore UNIX) - nel mondo MS, in genere si ha un certo numero di macchine sotto il proprio controllo strettamente legate a poche centrali repository e probabilmente saprai dove sono il più delle volte. (Questo si verifica quando si tratta di IIS, quindi molte app Web eseguono il controllo da parte degli utenti.)
Come menzionato in un'altra risposta , gli hash di Microsoft sono stati tradizionalmente deboli e probabilmente sono mantenuti in questo modo per compatibilità con le versioni precedenti. Ma non è nemmeno fondamentale per il loro modello di sicurezza - nel modello Microsoft, è relativamente banale cambiare una password. È relativamente banale forzare le tutte password da modificare. Hai anche un metodo robusto per le password in scadenza (quindi qualsiasi hash perso sta per perdere rapidamente il suo valore, sicuramente entro 1-2 mesi).
Stai anche operando in un mondo in cui amministratori benevoli hanno ascoltato utenti non tecnici attraverso le trappole dell'informatica; come solo un esempio: non salatura significa che puoi avere un utente che aggiorna la password mentre non è in grado di parlare con il controller di dominio e il controller di dominio può elaborare il nuovo hash della password semplicemente guardando le credenziali correnti dell'utente (utente + dominio + nuova password) e le loro precedenti credenziali. Questo è un grande vantaggio perché significa che l'esperienza dell'utente (cambiare le password ogni xxx giorni) non cambia in base all'accesso alla rete.
Potresti essere interessato alla spiegazione tecnica Microsoft del loro sistema di password .