In che modo i client si registrano utilizzando SRP?

Nessuna di queste opzioni è ottima, sebbene (1) sia la peggiore. La linea di fondo è che SRP è un'idea fantastica, ma è difficile vedere come distribuirlo. Soprattutto perché il supporto del browser è patchy - plug-in di qualità beta per una manciata di browser.

Se vuoi creare un sito di lavoro pratico ora, usa (3).

Potresti, in teoria, usare (2) su SSL con Diffie-Hellman anonimo, quindi non c'è CA. In tal caso, al tuo primo scambio, non sai con chi stai parlando. Ma in futuro almeno sei sicuro che sia lo stesso sito. Quindi forse ti iscrivi all'inizio senza fiducia nel sito, accumuli fiducia nel tempo e hai la sicurezza che un utente malintenzionato non possa impersonare il sito di cui ti fidi.

Solleva alcuni problemi di fiducia più ampi e le modalità di transazione online. Molti consumatori apprezzano il modello di "So che Amazon è affidabile, voglio usarli" e il modello di CA esistente si adatta abbastanza bene. Se ti occupi maggiormente di accordi peer-to-peer e non gerarchici, come stabilisci la fiducia online?

La tua domanda riguarda solo la registrazione online - se hai un altro accordo, come la registrazione di persona, potresti avere opzioni migliori.

Innanzitutto, poiché i browser non supportano SRP, stiamo necessariamente parlando di un'applicazione locale personalizzata.

Per motivi di sicurezza, è importante che il codice dell'applicazione locale sia "sicuro". Dobbiamo presumere che l'utente inizialmente non aveva l'applicazione, quindi l'ha ottenuta e l'ha installata sul suo computer. Ciò deve avvenire prima della registrazione SRP. Eppure gli utenti devono avere un modo per assicurarsi che il codice dell'applicazione che installano sia autentico e non ostile. Forse l'hanno preso da un CD-ROM / DVD; forse l'hanno scaricato attraverso un "canale sicuro"; forse il file binario è firmato. L'utente malintenzionato vorrebbe inserire il proprio codice in quella applicazione, quindi ci deve essere un meccanismo per sconfiggere l'attaccante a quel punto.

Supponendo che il codice dell'applicazione sia sicuro, allora quel codice applicativo potrebbe incorporare una copia di una chiave pubblica di proprietà del tuo server; per esempio. una copia del certificato del server. Tale certificato può essere autofirmato, o emesso da una CA personalizzata, o qualsiasi altra cosa: poiché l'applicazione conosce a priori la chiave pubblica del server, può stabilire un tunnel sicuro con il server tramite SSL, e senza coinvolgendo una CA esterna: l'applicazione controlla solo che il certificato utilizzato dal server sia bit-to-bit identico a quello incorporato. A quel punto, puoi trasmettere qualsiasi password scelta dall'utente senza paura di intercettazioni ostili. Probabilmente, potresti continuare a utilizzare tale SSL e non eseguire alcun SRP.

Il modello della "chiave pubblica incorporata" è semplice e funzionerà, ovvero se non funziona, significa che hai un problema di sicurezza più grande che non puoi risolvere con qualsiasi quantità di SRP.

Come nota a margine, questo esempio mostra che SRP, sebbene un algoritmo massicciamente spinto, non è necessariamente utile in contesti in cui il codice dell'applicazione personalizzato, specifico del server è installato sul lato client. La vera bontà di SRP si verifica quando il codice client è generico , ad es. è un browser Web che non include alcun codice specifico del sito. Ma non siamo ancora là; i browser non sanno come fare SRP (per ora ...).

o

4. il client registra il verificatore utilizzando TSL utilizzando un certificato autofirmato
5. il client registra il verificatore crittografato con una chiave pubblica RSA vanilla dei server.

Una domanda correlata parla di queste opzioni al link

Nel contesto di SRP come prova di una password per un sito Web, idealmente si desidera utilizzare un certificato e un HTTPS con firma CA per garantire che l'utente si registri con il server corretto. Puoi anche utilizzare HTTPS all'accesso per proteggere l'identità dell'utente. Quindi hai difesa in profondità. Se non si vuole andare con un certificato firmato dalla CA, allora uno autofirmato può impedire l'intercettazione del verificatore e del nome utente, ma l'utente è più a rischio di registrarsi con un sito falso. Ci sono molti motivi per non fare affidamento solo su TSL e vedere SRP come gratuito da usare entrambi (ad es. Heartbleed ) ma questo è un po 'fuori tema rispetto alla domanda. La linea di fondo è che se la password non deve essere copiata nella memoria del server, in realtà non dovrebbe esserlo.

La caratteristica che "non hai bisogno di un'autorità esterna" è un angolo che SRP come estensione di TSL in RFC 5054 ha preso quale AFAIK non viene ampiamente adottato. Ciò potrebbe essere dovuto al fatto che amministratori di sistema e devops sono molto a proprio agio con TSL / HTTPS e certs e sono molto a disagio nel provare qualcosa di nuovo. La linea di fondo è che SRP per TSL sostituisce il "ottenere un certificato firmato" con "distribuire i verificatori in modo sicuro" e questo implica PKI quindi perché non usare solo certificati CA standard con TLS e stare su una buona rotta e bene setup documentato? Il costo di un certificato firmato era una barriera, ma ho acquistato quelli ufficiali per le banche a costi esorbitanti, ma ho comprato anche quelli personali per soli $ 25 da CA abbastanza discutibili. Quindi, in realtà l'angolo "non c'è bisogno di una CA" per SRP non è forse un driver tanto avvincente per la sua adozione oggi, come potrebbe sembrare alla sua invenzione. Crea anche uno stato mentale "o / o" e le persone dovrebbero essere inadempienti per usare entrambi ; utilizzare CA TSL per impedire l'intercettazione e per aiutare contro phishing e SRP come prova della password per evitare la perdita della password sul server e per difendersi da i proxy web aziendali ficcanaso .

Crea una chiave privata con verificatore corrispondente per il server. Piuttosto che usare un hash di una parola salata e una password come nel tipico SRP, basta usare un numero casuale (mod N) e non zero per il valore della chiave. Nelle implementazioni SRP, la chiave viene in genere chiamata "x", quindi il verificatore è g ^ x (mod N).

SRP con una chiave di 0 è semplicemente Diffie-Hellman.

Ora esegui un accesso SRP con i ruoli invertiti: il client riproduce il server, il server esegue il client, il server "accede" al client utilizzando la chiave privata del server, il client autentica il server con il verificatore pubblico del server.

Utilizzare la chiave concordata (stabilita dal protocollo SRP) per crittografare la sessione in cui il client invia il nuovo verificatore del client (NON la password) al server. In genere, il server invierà i valori corretti di N e g (che possono essere diversi da N e g usati per stabilire l'identità del server) più un salt casuale, quindi il client usa un hash del sale e la password come il nuovo chiave.

Si noti che il verificatore del server può essere un valore pubblico, quindi può essere incorporato nel codice sul lato client senza offuscamento. Dal momento che è stato creato utilizzando un numero casuale grande e non una password, non è possibile alcun attacco di dizionario, quindi è sicuro che sia pubblico. La chiave privata, ovviamente, deve essere tenuta al sicuro sul server, in quanto chiunque con quella chiave può mascherarsi da quel server.