Dopo l'attacco a Blizzard, quali passi posso fare per rendere più difficile il cracking offline di SRP?
La mia domanda presuppone che il tuo database sia già andato e che tu abbia implementato SRP più o meno correttamente.
Correlati: Quanto è sicuro l'SRP che Blizzard usa per proteggere le password?
In SRP, il server memorizza un token derivato da password, che può essere usato per indovinare la password in un attacco di dizionario offline (gli aggressori cercano potenziali password finché non viene trovata una corrispondenza). Questo non è un difetto di SRP: il server necessariamente contiene alcuni dati derivati da password simili, indipendentemente dal protocollo di autenticazione utilizzato. La magia di SRP è che nessun altro posto nel protocollo produce tali dati derivati dalla password (anche se l'hacker tenta di impersonare il server). Ma se il server stesso viene compromesso (tutti i suoi segreti sono noti all'attaccante), allora è possibile un attacco di dizionario offline.
Il potenziamento di questo token riguarda i soliti strumenti, ovvero sali e iterazioni (vedi bcrypt ). In pratica, ciò significa che l'output di bcrypt viene utilizzato come "password" in SRP.
Ci sono due opzioni. SRP calcola un hash della password dell'utente, quindi esponenzia e registra il risultato. Opzione 1: è possibile sostituire l'hash con un "hash lento": raccomando PBKDF2. Opzione 2: è possibile pre-hash la password con PBKDF2, quindi utilizzare il risultato come prima. Fornisco una proposta dettagliata nella mia risposta a Posso utilizzare una funzione di derivazione chiave come la funzione hash H in SRP? ; per favore vedi la mia risposta lì per la matematica dettagliata. Ciascuna di queste opzioni risolverà il tuo problema.
Related:
Sono sorpreso che le persone non abbiano notato che puoi e devi crittografare il verificatore nel db. Tipicamente con le grandi aziende i database sono infrastrutture segregate. Anche il regime di backup dei server di database è deliberatamente diverso dai backup a livello di host dei server delle applicazioni e dell'infrastruttura web. I backup Db sono solitamente fuori sede e su nastro con un lungo periodo di conservazione. Ci sono anche tipicamente diversi specialisti e team che si occupano dell'infrastruttura e dei backup db. In questo caso, la crittografia del verificatore è ovviamente un'ulteriore protezione dai nastri che viene persa dal corriere che li sposta fuori sede.
Se crittografate il verificatore, c'è la domanda su dove tenere e fare il backup delle chiavi di crittografia. Grandi aziende come le banche hanno dovuto risolvere questo problema per le loro chiavi SSL e password insieme ad altre configurazioni di sicurezza sensibili. Non li metteranno sugli stessi nastri dei backup db. Normalmente avrebbero una rete di sicurezza segregata che può gestire gli host della linea frontale e avere due host (o due teste NFS dedicate) in due data center su quella rete copiata da unison / rsync per eseguire il backup di una copia delle chiavi di crittografia e della configurazione di sicurezza .
Mettendo tutto insieme dovresti avere una posizione di configurazione sicura o condividere sui server delle applicazioni che sono esclusi dai backup a livello di host. In quella posizione si inserisce una chiave simmetrica che legge solo l'id utente del server delle applicazioni. L'applicazione quindi usa quello per crittografare / decodificare il verificatore SRP dell'utente in quanto viene salvato / caricato nel db principale. Le chiavi di backup su host segregati in ciascun data center. Se perdi assolutamente tutto, ricostruisci il tuo db dai nastri fuori sede e crei una nuova chiave simmetrica. Tutti i tuoi usi non saranno più in grado di accedere ma useranno semplicemente la logica di reimpostazione della password per impostare un nuovo verificatore.
Leggi altre domande sui tag cryptography passwords hash key-exchange threat-mitigation