L'autenticazione PKE può essere utilizzata come alternativa migliore a SRP?

2

Se ho capito bene l'SRP, il suo punto debole è durante la registrazione di un utente quando si invia il verificatore al server.

Diciamo che il Server conosce il PubKey (Utente) dell'Utente e l'Utente conosce il PubKey (Server) del Server. Per l'autenticazione il server invia un segreto casuale crittografato con PubKey (utente) all'utente. L'utente decrittografa il segreto con il suo PrivKey (Utente) e lo crittografa con il PubKey (Server) e lo rimanda. Dopo averlo fatto, il server decrittografa il segreto con PrivKey (Server) che lo confronta con quello inviato all'utente, se è corretto, l'utente è autenticato.

Sarebbe più sicuro dell'SRP e offrirti lo stesso vantaggio (non memorizzare le password utente) come SRP?

    
posta PKEvsSRP 06.10.2015 - 10:08
fonte

2 risposte

2

Quando dici

Let's say the Server knows the PubKey(User) of the User and the User knows the PubKey(Server) of the Server.

stai presentando un problema molto più facile di quello che SRP deve risolvere. Molto semplicemente, se ciascuna delle parti conosce già le chiavi pubbliche dell'altra parte, allora abbiamo finito. Tutta l'autenticazione reciproca e lo scambio di chiavi sono quindi facili. Nessun segreto (come il verificatore SRP) dovrebbe mai essere trasmesso, né sarebbe necessario memorizzare eventuali segreti al di là delle proprie chiavi private.

SRP e altri PAKE (sistemi di scambio di chiavi con autenticazione basata su password) diventano inutili in un mondo in cui le parti comunicanti conoscono già le altre chiavi pubbliche.

    
risposta data 07.10.2015 - 16:28
fonte
2

L'intero punto del meccanismo di scambio di chiavi autenticato da password è quello di abilitare la creazione di un segreto condiviso quando i due le parti non hanno un meccanismo di autenticazione reciproca migliore rispetto a un segreto condiviso a bassa entropia (la password).

Se il cliente può sapere, con una certa sicurezza, la chiave pubblica del server, allora il client può semplicemente usare quella conoscenza per aprire un tunnel sicuro con il server e inviare la password in quel tunnel. Questo è ciò che accade quando un utente umano con un browser Web si connette a un server HTTPS e digita la sua password: il client autentica il server grazie al suo certificato, e questo è sufficiente per attivare un SSL, a quel punto la password può essere inviato "così com'è" poiché il client ha una certa garanzia che stia parlando al server previsto.

Pertanto, se si inizia assumendo che il client conosca la chiave pubblica del server, non è necessario utilizzare SRP. Inoltre, se si assume che il server conosca anche la chiave pubblica del client, non è più necessario utilizzare una password.

Considera la registrazione della password: prima di tale operazione, non esiste un "segreto condiviso" tra client e server. Tuttavia, il cliente utilizzerà in seguito tale conoscenza del segreto condiviso per autenticare il server. Ciò significa che al momento della registrazione deve essere utilizzato un altro metodo di autenticazione, in base al quale il cliente può accertarsi che stia impostando le cose con il vero server.

È possibile immaginare il caso di un client che si registra tramite un'interfaccia Web alimentata tramite SSL (il certificato del server viene utilizzato dal client per assicurarsi che parli al server originale); quindi la password registrata verrà utilizzata successivamente, ad es. da un dispositivo client in cui la convalida dei certificati non può essere effettuata convenientemente.

    
risposta data 07.10.2015 - 17:16
fonte

Leggi altre domande sui tag