TL; DR : a causa di come Windows autentica gli utenti della rete in scenari non Kerberos (non Active Directory), gli hash delle password funzionano altrettanto bene delle password per l'autenticazione degli utenti della rete.
Versione lunga : esistono due metodi tradizionali per utilizzare una password per autenticare qualcuno:
- Il client invia la password al server (tradizionalmente, in chiaro, sebbene i nuovi protocolli utilizzino la crittografia). Il server prende la password, la blocca e la confronta con l'hash della password che ha memorizzato. Se gli hash corrispondono, si presume che il client abbia la password corretta e sia considerato come autenticato.
- Challenge-response: il server genera una sfida (una sequenza di byte casuale) e la invia al client. Il cliente accetta la sfida, la combina con la password del client, esegue il hash del risultato e invia l'hash al server. Nel frattempo, il server accetta la sfida, la combina con la password che ha memorizzato e il risultato è stato cancellato. Se i due hash corrispondono, il client viene considerato come autenticato.
Si noti che, in uno schema challenge-response, la password non viene mai effettivamente inviata al server (che è buona), ma il server deve conoscere la password (che è male). Il primo approccio è il tradizionale approccio Unix; il secondo è l'approccio tradizionale di Windows.
Per attenuare il "server ha bisogno di conoscere la password", lo svantaggio della challenge-response, molte implementazioni challenge-response utilizzano un hash della password. In altre parole, invece di confrontare l'hash di (challenge + password) , le implementazioni confrontano l'hash di (challenge + hashed password) . Tuttavia, in questo caso, la password hash è ancora tutto ciò che serve per accedere al servizio (perché un client malintenzionato può inviare l'hash di (challenge + hashed password) anche se non conosce la password cleartext). Quindi le password di hashing nell'ambito di uno schema di risposta alle sfide rendono più difficile ottenere una password in chiaro che potrebbe presumibilmente essere utilizzata per attaccare altri servizi, ma non fa alcuna differenza in termini di sicurezza del servizio stesso.
Ulteriori letture e riferimenti:
-
link
Once hashes are obtained, cracking them to uncover the plaintext password can be a long and arduous task (assuming the passwords don’t succumb to wordlists or rainbow table attacks). Luckily for us, Windows will gladly accept NTLM hash values in many situations, such as accessing a network resource by its IP address (vs. hostname) or connecting to a device that isn’t joined to the Domain. The only only time hashes would not be exchanged would be when requesting network resources in a Kerberos-exclusive environment, but that type of implementation is rare and can be problematic for many organizations to implement.
-
link
Many (but not all) challenge-response algorithms… require both the client and the server to have a shared secret. Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords.
-
link
The UNIX scheme typically sends clear-text passwords over the network when logging in. This is bad. The SMB encryption scheme never sends the clear-text password over the network, but it does store the 16-byte hashed values on disk. This is also bad. Why? Because the 16 byte hashed values are a “password equivalent.” You cannot derive the user's password from them, but they could potentially be used in a modified client to gain access to a server. This would require considerable technical knowledge on behalf of the attacker but is perfectly possible. You should therefore treat the data stored in whatever passdb backend you use (smbpasswd file, LDAP) as though it contained the clear-text passwords of all your users.