Implementazione di SRP senza memorizzare il sale ovunque

0

Sto tentando di utilizzare SRP per verificare i client quando eseguono l'autenticazione con un server web, in modo che la password non venga mai inviata sul filo.

Osservando la procedura SRP , quando un client si registra con il server invia v ( verificatore), s (sale) e I (nome utente o identificatore) al server che memorizza questi valori. Tuttavia, si afferma che:

[The salt] could be chosen by either side but is done by [the client] so
that [it] can register I, s and v in a single registration request.

Se il sale può essere scelto dal server o dal client, allora possiamo semplicemente supporre che il server lo generi.

Quando il client tenta in seguito di autenticarsi con il server, il client invia I e il server risponde con s . Quindi il client utilizza s e altri dati per preformare la prova della password.

La mia domanda è: perché s statico? Perché deve essere conservato affatto?

Il sale viene inviato a chiunque lo richieda e, a causa di ciò, un utente malintenzionato potrebbe tentare di creare una tabella arcobaleno mirata richiedendo il sale di un utente specifico. Questo viene visualizzato in questa domanda , al punto 2 #.

Non fornirebbe più sicurezza per il server di generare in modo casuale un sale su un ClientHello messaggio? Su ogni richiesta separata, sarebbe inviato un sale diverso , evitando che l'attaccante possa compilare una tabella arcobaleno mirata. Inoltre, il sale non verrebbe memorizzato sul server, il che renderebbe l'informazione ancora meno utile in caso di violazione dei dati.

In particolare, questo metodo potrebbe aprire un vettore di attacco in cui l'attaccante avvia continuamente la procedura di autenticazione fino a quando il server non risponde con un sale favorevole. Tuttavia, se l'entropia del sale s è sufficientemente grande, ciò non sarebbe fattibile. Inoltre, il server potrebbe limitare il numero di tentativi di autenticazione per username I , in modo che un utente malintenzionato non possa eseguire questo attacco in parallelo con una botnet

  • Ad esempio: dopo aver avviato un tentativo di autenticazione per I , il server non ha risposto ai successivi tentativi di autenticazione come I entro un intervallo di tempo di dire, mezzo secondo.
posta FRZ 27.11.2018 - 02:10
fonte

1 risposta

1

Hai assolutamente ragione nel ritenere che il sale pubblicamente disponibile porti con sé alcuni rischi per la sicurezza (che tornerò a), ma prima lascia che indico perché il sale deve essere statico.

Il client deve essere in grado di derivare dalla password fornita dall'utente il x che corrisponde al verificatore, v che il server ha memorizzato. Il client si autentica sul server provando che sa (o può calcolare) x mentre il server si autentica sul client dimostrando di conoscere v .

Ciò significa che il client dovrà derivare lo stesso x ogni volta, poiché è matematicamente correlato al v che il server memorizza. Il client calcola x dalla password e sale. Per produrre lo stesso x ha bisogno della stessa password e sale ogni volta.

Rendere opaco il sale

Come tu (e altri) hai notato, il fatto che il sale sia completamente pubblico significa che un attaccante non ha bisogno di aspettare che una violazione del server inizi a scoppiare. L'utente malintenzionato può precomputare un gran numero di candidati v e quindi nel caso di una violazione del server, quando viene scoperto il vero v , l'utente malintenzionato può vedere se è < em> v per cui hanno una password da indovinare.

Questo problema è vero per ogni precedente (asimmetrico) PAKE, come indicato in un brillante articolo pubblicato all'inizio di quest'anno: OPAQUE: An Protocollo PAKE asimmetrico sicuro contro gli attacchi pre-calcolo . Gli autori propongono una nuova costruzione che avvolge un PAKE più tradizionale in un modo che non soffra di questo problema.

Anche se sono il principale contributore di un'implementazione SRP , ho pubblicato la seguente immagine dopo aver appreso di OPAQUE .

    
risposta data 30.11.2018 - 01:19
fonte