SRP è progettato per proteggere la trasmissione della password dagli attacchi brute-force, anche nel caso in cui la password possa essere facilmente rinforzata.
Tuttavia, se alcuni server di autenticazione di Blizzard sono stati compromessi, i relativi vettori di attacco sono diversi. Oltre allo schema di archiviazione, l'avversario può anche ascoltare le transazioni in corso e, in parallelo, memorizzare i segreti temporanei DH generati dai server SRP. Quest'ultimo attacco è un po 'complicato e richiede una preparazione approfondita da parte degli aggressori, tuttavia, sicuramente verrebbe a mancare qualsiasi login utilizzato per autenticare il sistema compromesso.
Il vettore di attacco più tradizionale sono i valori di verifica. In SRP, i valori del verificatore sul lato server non sono gli hash tradizionali ma i risultati di un esponenziamento, come in Diffie-Hellmann.
A mia conoscenza non esiste un'analisi dettagliata di SRP vs. PBKDF2 o bcrypt. Da qualche parte sul sito SRP (srp.stanford.edu) Una volta ho visto una nota che le persone hanno implementato un bruteforcer e hanno scoperto che lo sforzo di bruteforcing richiesto era simile alla tradizionale bruteforcing degli hash.
Questo è come previsto: è noto che tali esponenziamenti sono difficili da invertire, proprio come una funzione hash. Supponendo che Blizzard abbia implementato un protocollo standardizzato come RFC2945 e non abbia tentato di inventare i dettagli da soli, questi valori di verifica conterranno anche un sale per rendere le tabelle arcobaleno poco pratiche.
La principale differenza è quindi nello sforzo di forzare la personalizzazione dei valori di verifica individuali. Qui, sistemi come bcrypt / PBKDF2 impiegano un fattore di scala per aumentare lo sforzo computazionale per ogni ipotesi di password. Gli schemi SRP che conosco non supportano esplicitamente questo. L'esponenziazione è in genere un calcolo un po 'più costoso rispetto a un hash, ma dipende dal gruppo (modulo) in cui stai operando. Penso che aumentare il modulo del valore di verifica in SRP sia facilmente possibile, ma aumenterà anche lo sforzo di calcolo per altri 2 esponenziamenti per peer che devono essere eseguiti in ogni esecuzione del protocollo.
Aggiornamento: guardando ancora una volta l'RFC2945, la password e il sale vengono prima sottoposti a hash e quindi esponenziati. Sarebbe facile usare PBKDF2 qui invece di limitarsi a implementare un fattore di scala per lo sforzo bruteforcing senza influire molto sul resto del protocollo. Inoltre, anche quando è stato scelto un esponente N piccolo / non idoneo, lo schema è ancora sicuro quanto una semplice autenticazione basata su challenge-response.
Nel complesso, Blizzard è probabilmente un po 'fortunato dato che il loro tipo di memorizzazione pw è molto raro e gli agenti brute appropriati non sono comunemente disponibili. Tuttavia, per un determinato attaccante il modo SRP di memorizzare i segreti non è più sicuro (forse un po 'meno sicuro) rispetto all'approccio allo stato dell'arte con un fattore di scalabilità decente anti-bruteforce. Detto questo, mi congratulo con Blizzard per l'utilizzo di una crittografia avanzata per la loro autenticazione con password, dal momento che la bruteforcing online è in genere molto più problematica.