Come per i database degli hash delle password, l'approccio tradizionale per prevenire gli attacchi basati sul dizionario è quello di rendere gli hash di calcolo (o in questo caso i verificatori) dalle password abbastanza costose.
Nel caso dell'SRP, il modo più ovvio per farlo è scegliere un gruppo abbastanza grande. (In ogni caso, deve essere abbastanza grande da resistere alla crittanalisi, come con RSA o DH.)
Ovviamente, l'aumento della dimensione del gruppo rallenterà anche client e server.
Un'altra possibilità è di sostituire SHA-1 con un'altra funzione di hash come suggerito nella sezione 3.2 di RFC 2945. Il costrutto SHA-1 salato usato in SRP-SHA1 può essere sostituito da un altro digest di messaggio, o da HMAC o da un funzione di hashing della password.
A mio parere, usare una buona funzione di hashing della password come Argon2 o BCrypt o PBKDF2 invece di SHA-1 ha senso. In questo modo aumenta il costo degli attacchi di dizionario senza avere alcun impatto sulle prestazioni del server. (Tuttavia, le prestazioni del client sono influenzate). D'altro canto, ciò non migliora la resistenza alla crittanalisi.
SRP è progettato per proteggere le password in un modello di minaccia che presuppone che un utente malintenzionato possa accedere alla memoria del server. Pertanto, SRP è progettato per essere sicuro in un contesto in cui un utente malintenzionato potrebbe accedere alla tua password principale.
Questo sopra indica anche che SRP è in realtà in concorrenza con i gestori di password, essendo la successiva una soluzione più diffusa. SRP è in gran parte inutile se gli utenti utilizzano già gestori di password con una password univoca per ciascun sito.
La crittografia dei verificatori memorizzati è essenzialmente la stessa di "peppering" di un database delle password. Questo aggiunge un bel po 'di complessità. Se ciò migliora la sicurezza del sistema non è ovvio.
Questo ha senso solo se si presume che l'attaccante abbia accesso al database ma non al server (mentre l'uso di SRP ha senso solo se si presume che l'utente malintenzionato abbia accesso al server), la password principale ha una buona entropia e la crittografia il codice è scritto correttamente (gli IV sono generati correttamente ...)
Per quanto riguarda l'utilizzo di Argons2, è necessario correggere i parametri: utilizzare la quantità di memoria e potenza di elaborazione che si può permettere. Non fare in modo che i parametri dipendano dalla password.