Per avviare uno scambio di chiavi utilizzando il protocollo SRP il client invia il nome utente in modo che il server possa cercare il verificatore di sale e password. C'è un modo semplice per cambiare questo in modo che un utente maltrattato non possa scoprire il nome utente?
Penso che un altro Diffie-Hellman potrebbe prendersene cura, ma il protocollo SRP è così simile che mi chiedo se c'è un modo per unirlo senza troppo sovraccarico.
Diffie-Hellman non aiuterebbe qui: un attaccante attivo potrebbe usare un classico MITM e vedere qualunque dato debba essere protetto dal tasto DH. Avrebbe visto lo scambio SRP solo "dall'esterno" ma avrebbe comunque imparato il nome utente.
Il non anonimato dell'utente che effettua la connessione è una proprietà piuttosto fondamentale degli algoritmi Scambio chiavi autenticati tramite password . Tali protocolli resistono agli attacchi di dizionario offline perché entrambe le parti prendono impegni specifici per le password nelle prime fasi del protocollo.
In SRP, il server dovrebbe scegliere un b casuale e inviare B = v + g b al client. Un server falso non sa v ma vorrebbe impararlo, perché conoscere v consente un attacco di dizionario offline (vale a dire, "provare" le password fino a una corrispondenza, sul il computer di un utente malintenzionato, senza interagire più con l'utente o il server reale). Tuttavia, a causa della difficoltà del logaritmo discreto, un utente malintenzionato non può sapere sia v che b che corrispondono a un dato B , a meno che non scelga < em> v e b e calcolato B da quei valori. L'attaccante non può guardare indietro al suo messaggio passato e pensare cose come: "bene, supponiamo che al posto del v che ho usato, avrei dovuto usare v ' perché è quello che il cliente potrebbe aver capito "; se lo fa, perde conoscenza di b , e senza la conoscenza di b è "al di fuori" del successivo scambio Diffie-Hellman (SRP è ancora, nel suo nucleo , un Diffie-Hellman con le campane accese). In questo modo, B è un impegno: il server si impegna a un determinato valore dipendente dalla password v quando invia B , perché non sarà in grado di ottenere alcuna informazione utile dal resto del protocollo a meno che non continui a usare quell'esatto valore di v . Questo è dove si verifica la magia PAKE: questo impegno fa in modo che un utente malintenzionato debba interagire con l'utente o il server reale o entrambi per la password ogni che sta indovinando. Questo riduce gravemente l'efficacia degli attacchi di dizionario, e questo è il punto dei protocolli PAKE.
Poiché il server deve eseguire il commit a un determinato valore dipendente dalla password all'inizio del protocollo ( prima l'autenticazione è effettivamente avvenuta), il server deve sapere di quale password stiamo parlando, quindi un identificatore utente inviato "in chiaro".
Per preservare l'anonimato degli utenti riguardo agli intercettatori, il server deve prima essere autenticato dal client in modo indipendente dall'utente, che è ciò che ottieni da un TLS tunnel con certificati server, ma se si utilizza SRP, non è esattamente per evitare l'uso di certificati? Inoltre, in una configurazione relativa a Internet, l'intercettatore apprenderà ancora l'indirizzo IP dell'utente, che in molti casi è quasi buono come un nome.
Se vuoi solo difendermi da un intercettatore passivo, allora c'è un modo semplice: configura una connessione crittografata tra il client e il server, quindi invia tutti i messaggi SRP tramite questa connessione crittografata.
In pratica, un approccio pragmatico sarebbe quello di impostare una connessione SSL o una VPN tra il client e il server e inviare tutto su questo tunnel crittografato. Se il client non controlla il certificato del server, questo è protetto contro intercettazioni passive ma non contro un attaccante attivo (un man-in-the-middle).
Se il client controlla il certificato del server, sarà sicuro anche contro gli attacchi e gli attacchi MITM attivi (fino alla possibilità del client di verificare il certificato del server).
Puoi sempre proteggere il contenuto (anche le credenziali di accesso) utilizzando la crittografia, in genere trasporta la crittografia come SSL.
Il rollare la tua base crittografica usando DH o qualcosa di simile è generalmente una cattiva idea; usare qualcosa di stabilito (ancora, come SSL) aiuta a proteggerti dalle insidie che potresti non aver previsto. Ad esempio, il problema con la crittografia simmetrica con una chiave generata da DH è che si tratta di crittografia senza autenticazione. Il client ha una connessione sicura a qualcuno , ma non sa se quel qualcuno è il server o se è un aggressore MITM. L'autenticazione basata su certificato in SSL protegge da tale possibilità.
Quindi, stabilire una connessione crittografata dal client al server, utilizzando un certificato con firma pubblica per l'utilizzo generico o generare il proprio certificato di firma se l'applicazione è l'unico client. Quindi, una volta stabilito il collegamento crittografato, THEN invia le credenziali di accesso e così via. Inoltre, è possibile mantenere la connessione crittografata in seguito, poiché il sovraccarico è minimo e la maggiore sicurezza è significativa.
Leggi altre domande sui tag authentication cryptography encryption passwords key-exchange