Come si può combinare l'archiviazione delle password salate e hash con un'identificazione basata su testo in chiaro, nonce e hash?

Sì, questo è possibile. Esistono due algoritmi descritti qui che evitano entrambi la necessità di archiviare gli equivalenti in testo normale sul server (rendendo possibile l'autenticazione senza la necessità di inviare password in chiaro sul filo).

Dai un'occhiata al protocollo Secure Remote Password ( wikipedia , Stanford ). Usa un hash della password (scegli il tuo hash lento e salato preferito) sul lato client, ma il server riceve solo un "verificatore" derivato da che hash per esponenziazione discreta. L'autenticazione effettiva avviene tramite uno scambio di chiavi asimmetrico utilizzando due numeri casuali (uno generato dal client, uno generato dal server), l'hash (solo lato client) e il verificatore (lato server). È inteso che la chiave generata sia utilizzata per crittografare il resto della sessione, ma potrebbe semplicemente essere verificata e scartata.

I vantaggi:

• Lo scambio di chiavi in sé è effettivamente una prova a conoscenza zero, il che significa che un ascoltatore, man-in-the-middle o server impostor non ottiene informazioni sulla password. Se questi fossero gli unici tipi di attacco possibili, una password a singola lettera sarebbe sufficiente per la sicurezza.
• Un attacco del dizionario online (impostore del client) può testare solo una password per tentativo (le prime versioni del protocollo ne consentivano due).
• Se un utente malintenzionato copia il database dei verificatori del server, può eseguire un attacco di dizionario offline solo eseguendo ciascuna password candidato attraverso l'esponenziazione lenta hash e . Non possono usare il verificatore per impersonare il cliente.
• Finché il verificatore del server rimane segreto, la transazione di scambio verifica in modo efficace il server per il client (e anche il client per il server).

Correggimi se ho torto ma, potresti mantenere la password con hash sul server. quindi è conservato in modo sicuro. e usa il nonce come sale per l'autenticazione. Una cosa importante che vedo è che il server non ha bisogno di conoscere la password in questo modo. Può ancora provare che la persona ha inserito la password corretta alla fine, ma confrontando gli hash, non il testo in chiaro. L'unico posto in cui questa password sarebbe in chiaro nel mio scenario sarebbe la finestra web broswer prima che venisse cancellata (due volte, una volta sola e una volta con sale noto) e poi inviata sul filo non in testo semplice

Considera lo scenario seguente

1. Il client tenta di connettersi
2. Il server genera nonce
3. Il server invia nonce al client. Rinnova l'hash con nonce come sale. un hash che accetta l'hash della password come input e il nonce come salt.
4. Il client esegue il hashing tramite lo stesso algoritmo di hash, generando lo stesso hash che viene memorizzato sul server.
5. Il client quindi esegue il proprio hash individuale allo stesso modo del server (un hash dell'hash del pwd con nonce come salt)
6. Il client trasmette l'hash non crittografato al server.
7. Il server lo accetta come corretto per quell'unica ora di autenticazione e non accetterà più lo stesso hash non forzato