Sfida, autenticazione e chiave di sessione

Il tuo protocollo è abbastanza sottodescritto, ma alcune osservazioni possono ancora essere fatte:

• Nel primo passaggio, il "salt" viene scelto casualmente dal client e inviato insieme al valore hash, nel qual caso questo passaggio appare completamente inutile; o il sale è non inviato dal client, ma è un valore segreto precondiviso tra client e server, nel qual caso non è un salt ma un tasto e il resto del protocollo è completamente inutile.

• Nella seconda fase, il client invia il suo login e la "password hash" in cui l'hash utilizza un po 'di sale. Se il client invia sempre lo stesso valore di hash, la presentazione del valore hash garantisce l'accesso: è equivalente alla password . Qualsiasi attaccante che osserva una connessione (puramente passiva) impara quindi a simulare l'autenticazione, quindi il protocollo sarebbe estremamente debole.

Se il tuo protocollo deve avere alcun valore, allora dobbiamo presumere che le cose vadano in questo modo:

• Il client si connette; server invia un valore casuale N (il termine tecnico è un nonce ).
• Il client invia un altro valore casuale N ' al server (e invia anche un valore hash calcolato sui valori pubblici N e N' ; tale valore di hash non ha alcun scopo utile).
• Il client invia il nome utente L e il valore h (N + N ', P) dove N e N' sono scambiati nonces, P è la password dell'utente, e h è una "funzione di hash" che in qualche modo combina N e P (ci sono molti metodi per fare questa combinazione, molti dei quali sono deboli in modi più o meno sottili).
• Il server ha una copia di P e quindi può ricalcolare il valore h (N + N ', P) e vedere se corrisponde a ciò che il client ha inviato.
• Il client e il server usano un'altra funzione h ' per calcolare h' (N, P) e usare quel valore come chiave condivisa per fare qualche crittografia simmetrica per il resto dei dati.

Supponendo che tu abbia fatto tutto correttamente e usato le funzioni di hash in modo corretto e non abbia dimenticato di aggiungere controlli di integrità e si siano presi cura dei gazillions dei dettagli di implementazione che possono affliggere i protocolli meglio progettati, allora avrai ottenuto, nel migliore dei casi , TLS-PSK . Ci sono due debolezze intrinseche e inevitabili in quel protocollo:

• Il server deve memorizzare un segreto equivalente alla password. Se un utente malintenzionato ottiene una visualizzazione di sola lettura dei dati del server (una consueta conseguenza di attacchi di SQL injection o di backup rubati), apprende abbastanza da autenticarsi come qualsiasi utente registrato. Questo è considerato negativo. Vedi questo post del blog per una discussione su questo argomento.

• Un attaccante passivo impara abbastanza per eseguire un attacco del dizionario offline : l'attaccante deve solo osservare un'autenticazione e quindi può "provare le password" sulle proprie macchine; elenca semplicemente le password possibili finché non ne trova una che corrisponda ai valori hash che ha osservato. Questo, ancora, è negativo, perché le password tendono ad essere vulnerabili a una ricerca così esauriente. Gli attacchi del dizionario online , in cui l'utente malintenzionato deve parlare con il server originale o il client originale per ogni tentativo di password, sono molto meno preoccupanti, perché il server può applicare rigorose limitazioni al numero di tentativi al secondo; mentre un attacco offline è limitato solo dal potere di calcolo che l'attaccante può radunare.

Il modo corretto di eseguire un'autenticazione reciproca basata su password client-server consiste nell'utilizzare un accordo chiave autenticato da password , che risulta in un segreto condiviso adatto per la crittografia simmetrica con controlli di integrità. Ciò significa fondamentalmente TLS-SRP . 15 anni di implementazioni e attacchi e correzioni hanno dimostrato che progettare e implementare un protocollo sicuro di questo tipo non è affatto facile.