Alimentando la creazione del verificatore da PBKDF2 a SRP

Question

Alimentando la creazione del verificatore da PBKDF2 a SRP

#1 da (4 voti)

4

C'è un gioco più vecchio che utilizza esclusivamente UDP per comunicare e volevo aggiungere l'autenticazione della password al gioco per facilitare cose come punti esperienza e classifiche. A tal fine, ho deciso di adottare un'implementazione di SRP-6a comunicata su UDP utilizzando un'estensione del protocollo di gioco esistente e ho finito con l'utilizzo di cocagne / csrp sul lato client del gioco, tramite tunnel attraverso il server di gioco e mozilla / node-srp su il lato server di autenticazione, leggermente modificato in modo da produrre la risposta di follow-up% c_srp-compatibile% _.

Ha funzionato abbastanza bene finora, tuttavia non sono un fan di come il verificatore è memorizzato a riposo, poiché sembra che nel processo di calcolo di HAMK gli input vengano solo sottoposti a hash una volta prima di trasformarsi nel verifier x , vedi qui . Ho suggerito di cambiare questa funzione di libreria in base alle nostre esigenze (dal momento che è ragionevolmente piccola e già in-tree) e utilizzare qualcosa sulla falsariga di PBKDF2. Tuttavia sto ottenendo (comprensibile) respingimento da un altro sviluppatore sul contatto con il codice di questa natura, buone intenzioni e tutto il resto.

È stato suggerito invece che forse la stessa password dell'utente sia sottoposta a hashing PBKDF2 prima di essere passata come password alla creazione del verificatore e alle funzioni di sfida dell'utente. In questo modo, non dobbiamo modificare alcun codice nella libreria csrp stessa. È un approccio valido? O c'è un'altra trappola per orsi in attesa di ingannarci se facciamo questo?

Per quello che vale, il documento di protocollo completo è qui , quindi se sto facendo altri tipi di snafus sarebbe bello saperlo.

passwords hash protocols srp

posta AlexMax 20.11.2014 - 00:50

fonte

1 risposta

Leggi altre domande sui tag passwords hash protocols srp

encodeURIComponent in un attributo HTML non quotato Memorizza la password di un utente in modo recuperabile

score 4 · Accepted Answer

La password in SRP è in realtà un segreto condiviso di (possibilmente) bassa entropia . Può essere la "password" come l'utente umano capisce, o tutto ciò che è deterministicamente derivato dalla password. Nel tuo caso, sì, usare una funzione di hashing della password come PBKDF2 è un approccio valido. Ha i seguenti avvertimenti:

PBKDF2, come bcrypt e altre buone funzioni di hashing della password, richiede un salt . Il sale è molto importante. Senza il sale, l'attaccante potrebbe ottimizzare gli attacchi in larga misura; vale a dire, avrebbe dovuto pagare per il passaggio PBKDF2 per un solo utente (se ha diversi hash memorizzati per diversi utenti di crack). Il punto qui è che il client e il server devono usare lo stesso sale per un dato utente, quindi il client deve sapere che sale in qualche modo. Ma il sale deve essere ancora specifico per ogni utente (e modificato ogni volta che l'utente cambia anche la sua password), quindi non puoi semplicemente indicarlo nel codice client.

Quindi è necessario memorizzare il sale per utente sul server, e per trasmetterlo al client come fase di autenticazione iniziale. In SRP, il client invia prima un messaggio contenente il nome utente ( I ) e un valore che non dipende dalla password ( A ). Il server risponde con il sale specifico dell'utente ( s ) e un altro messaggio ( B ). Dovresti inviare anche in quel messaggio server-to-client il sale extra necessario per PBKDF2.

In alternativa, è possibile sostituire il passaggio hashing in SRP con PBKDF2, ma ciò comporta la modifica del protocollo e delle librerie di implementazione, che probabilmente non è una buona idea. È più semplice e del tutto più sicuro aggiungere un ulteriore passaggio PBKDF2.

Si sta tentando di riutilizzare lo stesso sale di quello specificato da SRP (quello chiamato s nella specifica del protocollo). Anche se questo sembra crittograficamente sicuro qui (i due usi di sale essendo un po '"separati" con tutti i PBKDF2 tra di loro), questo genere di cose è noto per essere una questione di sottigliezza, e, ancora una volta, avere un extra, sale indipendente è il metodo sicuro e prudente.
PBKDF2 impiega molte iterazioni per rallentare gli attaccanti. Ma rallenta anche i normali utenti, quindi non puoi aumentare il numero di iterazioni quanto vuoi. Devi impostare il più alto che puoi tollerare, dato il carico e la potenza computazionale dei computer coinvolti, e i limiti della pazienza dell'utente.

Nel caso dell'integrazione con SRP, come con qualsiasi altro PAKE protocollo, il costo aggiuntivo dell'hash della password è sul lato client. Quindi il numero di iterazioni appropriato dipende dal computer client . Se si dispone di più client, è necessario adattarsi al computer meno potente che deve ancora essere in grado di connettersi. Questo punto è particolarmente cruciale per i client basati sul Web, con JavaScript, poiché JavaScript è molto debole per i calcoli grezzi, limitando strongmente il numero di iterazioni che è possibile tollerare. Nel tuo caso, il codice del client utilizza una libreria C, quindi puoi avere un po 'di muscoli lato client, ma dal momento che stai lavorando con un "vecchio gioco", devi considerare che il client potrebbe essere una "macchina più vecchia", forse un " elder machine". Ci sono alcuni pervertiti là fuori che ancora curano alcuni computer i486.
Puoi prendere in considerazione l'utilizzo di bcrypt invece di PBKDF2; bcrypt è probabilmente più strong contro gli attaccanti con GPU.