Come proteggere una connessione web-socket con challenge-response?

Question

Come proteggere una connessione web-socket con challenge-response?

#1 da (2 voti)

2

TL; DR Dato che tutte le informazioni di stato per un browser Web sono accessibili a un utente (potenzialmente ostile), come può essere considerata sicura l'autenticazione challenge-response tra il browser e il server?

Versione più lunga

Sto sviluppando un'applicazione web e voglio implementare socket web per la comunicazione tra il client e il server. Sto cercando di implementare un router WAMP e sto cercando di capire le modalità di autenticazione con un sistema come questo.

Il protocollo WAMP consente l'autenticazione challenge-response (CRA). Il modo in cui lo capisco (e per favore correggimi se ho sbagliato), quando un client effettua una richiesta di connessione, il server invia una richiesta. Il client quindi crittografa la richiesta utilizzando una chiave segreta condivisa tra il client e il server e la restituisce. Il server controlla la versione crittografata dal client e, se è stata crittografata correttamente, consente l'accesso. L'uso di un segreto condiviso consente al server di sapere che la richiesta proviene da un cliente autorizzato.

Questo porta alla domanda n. 1 : il codice Javascript inviato al browser deve contenere il segreto condiviso. Quindi il segreto condiviso non è molto segreto, vero? Quindi, come possiamo considerare questo un metodo di autenticazione sicuro?

Nel pensare a questa domanda, ho trovato una soluzione che penso possa risolvere il problema.

Nota importante: tutte le connessioni saranno protette tramite TLS.

Ecco come potrebbe funzionare il mio sistema di autenticazione:

l'utente accede tramite il normale metodo di autenticazione basato su modulo
genera una chiave di autenticazione e un segreto e passa tali valori al client come parte della pagina HTML. La chiave e il segreto sono entrambi generati tramite un metodo crittograficamente sicuro.
client avvia quindi la connessione websocket. Inizia la sequenza di autenticazione challenge-response, utilizzando la chiave e il segreto generato dal server
il server si autentica, usando la chiave & segreto, e tutto è bello.

La chiave qui è l'uso monouso della chiave e dei valori segreti. Se cambiano periodicamente, non è possibile che un utente malintenzionato generi una coppia chiave / segreta o ne usi una che aveva salvato da una visita precedente.

Che mi porta alla domanda n. 2 : si tratta di uno schema di autenticazione adeguato?

Infine, domanda n. 3 : supponendo che lo schema di autenticazione descritto sopra sia adeguato, con che frequenza dovrebbero cambiare i valori chiave / segreto? Sto pensando che dovrebbe cambiare definitivamente ogni volta che l'utente accede e dovrebbe scadere anche dopo 6-8 ore. Pensieri?

web-application challenge-response websocket

posta Kryten 01.09.2015 - 15:52

fonte

1 risposta

Leggi altre domande sui tag web-application challenge-response websocket

Associato di rischio con nonce e hash trovati nell'URL Applicazioni del profilo dall'analisi del traffico

score 2 · Answer 1

This leads to question #1: the Javascript code sent to the browser must contain the shared secret. So the shared secret is not very secret, is it? So how can we consider this a secure method of authentication?

Se studi la documentazione dell'autenticazione della risposta alla sfida con WAMP dovresti notare le seguenti informazioni:

The client and the server share a secret. The secret never travels the wire,

Si ritiene invece che il segreto sia stato condiviso prima di eseguire l'autenticazione:

The actual pre-sharing of the secret is outside the scope of the authentication mechanism.

In caso di utilizzo di Websockets dal browser probabilmente significa che il codice che contiene il segreto deve essere trasferito con TLS. Quando si utilizza Websockets all'interno di un'applicazione autonoma distribuita all'utente, il segreto può essere pre-spedito all'interno dell'applicazione. Poiché il segreto in sé non è specifico per l'utente ma è utilizzato solo per proteggere la comunicazione, può essere scambiato prima di qualsiasi tipo di autenticazione.

Important note: all connections will be secured via TLS.

WAMP-CRA è progettato esplicitamente per essere utilizzabile con non-TLS. Dalla documentazione:

... hence WAMP-CRA can be used via non-TLS connections

Ovviamente WAMP-CRA può essere utilizzato con TLS, ma se si dispone già di una connessione sicura non è necessario utilizzare un protocollo progettato per funzionare entro i limiti di TLS diversi, ma è possibile utilizzare un'autenticazione molto più semplice come i cookie o avvalersi dell'autenticazione reciproca fornita da TLS.

... Which brings me to question #2 ... And finally, question #3:

Poiché la tua ipotesi originale era sbagliata, non è necessario aggiungere sicurezza al protocollo esistente. Pertanto, non tratterò queste parti della domanda che riguardano la sicurezza del tuo livello di autenticazione aggiunto.

Ma una risposta più generale, indipendente dal framework che si utilizza: Websockets è un canale di comunicazione creato aggiornando una connessione HTTP (s) esistente. Ciò significa che qualsiasi tipo di autenticazione eseguita per la connessione HTTP (s) può essere applicata alla connessione Websocket, ad esempio l'autenticazione reciproca TLS, Autenticazione di base , cookie di sessione ecc. Pertanto, se la connessione HTTP (s) è già autenticata, non è necessario eseguire un'autenticazione aggiuntiva all'interno del canale Websockets poiché si tratta della stessa connessione TCP / TLS già autorizzata.