SRP è per situazioni in cui già hanno un segreto condiviso tra client e server, ad es. come parte di una procedura di "accoppiamento" che si verificherebbe naturalmente nel tuo contesto (ad esempio, SRP è stato proposto per le periferiche Bluetooth: un dispositivo ha uno schermo e visualizza un codice, l'altro dispositivo ha una tastiera su cui è inserito il codice) . Per una situazione "completamente online" dove non c'è mai l'occasione di ottenere un tale segreto condiviso, SRP ha un piccolo vantaggio. La sicurezza deve iniziare da qualche parte.
In SRP, ciò che il server memorizza è in effetti una sorta di hash della password - solo "ordinamento" perché il valore memorizzato deve anche soddisfare alcune strutture matematiche in modo che possa essere utilizzato nel protocollo. Quel valore non può essere immediatamente usato per l'autenticazione come client, ma, come ogni password con hash, è effettivamente suscettibile alla forza bruta. La magia di SRP è che l'osservazione dei pacchetti di dati sul filo non è sufficiente per applicare un attacco di dizionario sulla password; tuttavia, ciò che il server memorizza permette un tale attacco (e, in un modo molto generale, questo è inevitabile).
In TLS / SRP come attualmente specificato, il valore memorizzato sul server è calcolato come:
x = SHA1(s | SHA1(I | ":" | P))
v = g^x % N
dove s è il sale, I il nome utente, P la password e v è quello che è memorizzato ( x non è memorizzato). g e N sono parametri SRP (pubblici). Se l'autore dell'attacco può ottenere il valore v , allora può "provare le password" eseguendo il calcolo sopra.
Questo è un hash salato (va bene), ma è anche un hash abbastanza veloce (che è cattivo). SRP potrebbe essere abbinato a una buona funzione hashing password (ad esempio bcrypt), con i seguenti avvertimenti:
- Non esiste uno standard specificato o di fatto per quello. Ma sia il client che il server devono essere d'accordo sul particolare.
- Se viene utilizzato l'hashing lento, quindi, quando viene eseguita una connessione, deve avvenire sul client, non sul server. Quindi questo funzionerà alla velocità del client.