Inviando un hash della password, invece della password stessa, tutto ciò che stai proteggendo è il testo chiaro della password. Questo ha qualche merito, ma non fa nulla per proteggersi dagli attacchi di replay - questo è noto come pass-the -hash.
Combinando la password degli utenti con un sale monouso (challenge) fornito dal server, è possibile proteggersi da un tale attacco - ma per convalidare il token presentato (h (p + c)), il servizio ha bisogno per ricreare lo stesso valore di hash, ovvero è necessario memorizzare il testo in chiaro della password. Non va bene.
Convenzionalmente, un servizio di autenticazione memorizzerà un hash della password con un sale generato in modo casuale (h (s + p)), insieme al testo in chiaro del sale. Il testo chiaro del sale non è considerato particolarmente segreto - l'efficacia del meccanismo non è strongmente indebolita rivelando questo. Quindi, in linea di principio, il server poteva inviare sia una richiesta che il client avrebbe restituito:
h(h(s+p)+c)
Purtroppo, questo non risolve il problema del pass-the-hash poiché una conoscenza dei dati (h (s + p)) memorizzata sul server è sufficiente per essere in grado di autenticarsi.
L'unico modo pratico per evitare il problema è utilizzare un servizio di autenticazione affidabile sia dal client che dal servizio dell'applicazione - ad es. usando kerberos o openid - questo sposta semplicemente il problema nel servizio di autenticazione, ma questo separa e disaccoppia le responsabilità.