connessione sicura tra client e server

Question

sto sviluppando un componente server che servirà le richieste di un cliente incorporato, che è anche sotto il mio controllo.

In questo momento tutto è beta e la sicurezza funziona in questo modo:

1. client invia il nome utente / password su https.

2. ritorna server di accesso token.

3. client effettua ulteriori richieste su HTTP con il token di accesso in un header personalizzato.

Questo va bene per una demo, ma ha alcuni problemi che devono essere fissati prima di rilasciarlo:

• Chiunque può copiare una richiesta login, re-inviarlo e ottenere un token di accesso posteriore. Come alcuni utenti risposto questo non è un problema dal momento che va oltre https. Il mio errore.

• Chiunque può ascoltare e ottenere una chiave di accesso solo esaminando le intestazioni di richiesta.

mi viene in mente una crittografia a chiave simmetrica, con un timestamp in modo da poter rifiutare le richieste di duplicati, ma mi chiedevo se ci sono alcune buone pratiche ben noti per questo scenario (che sembra un abbastanza comune).

Grazie mille per l'intuizione.

PS:. Sto usando Java per il server e il client è scritto in C ++, nel caso in cui

Answer 1

Non capisco la prima parte, se la richiesta di accesso è https, come si può semplicemente copiarlo?

Per quanto riguarda la seconda parte, t Questo è uno scenario abbastanza standard dirottamento di sessione. Vedi questa domanda . Naturalmente non si ha il built-in opzioni del browser qui, ma l'idea di base è lo stesso -. O inviare il token solo tramite una connessione sicura quando conta, o in qualche modo associare il token con il dispositivo di invio

In un browser, in pratica tutto quello che hai è l'indirizzo IP (il che non è molto buono), ma nel tuo caso si può essere in grado di esprimere qualcosa specifiche sul dispositivo che si convalidare contro la richiesta per garantire lo stesso isn Token 't in uso da qualche altra parte.

Edit: Si potrebbe semplicemente essere fortunati qui ed essere in grado di escludere l'indirizzo IP cambia dietro proxy, ed effettivamente utilizzare per questo scopo

.

Ma alla fine della giornata, è molto più sicuro l'utilizzo di HTTPS da una libreria ben noto e rivisto piuttosto che cercare di rotolare il proprio qui. Mi rendo conto che è un overhead https, ma posizionare il proprio ha grossi rischi in tutto mancante cose ovvie che un utente malintenzionato può sfruttare.

Answer 2

Prima domanda, solo per farlo là fuori: Se sei preoccupato abbastanza nefasto client-imitatore accessi, perché non effettuare l'intera conversazione su HTTPS? È la performance minima colpito abbastanza significativo per questa applicazione che non vale la pena l'ulteriore livello di sicurezza?

In secondo luogo, come qualcuno può riprodurre la richiesta di accesso? Se non mi sbaglio, che sta avvenendo su HTTPS; se la connessione è impostato correttamente, HTTPS impedisce attacchi di riproduzione utilizzando nonces sola volta (vedi qui ).

Answer 3

Una delle raccomandazioni comuni è - utilizzare https

https attacco man in the middle parte utilizzando il protocollo HTTPS per l'intera sessione dovrebbe essere abbastanza affidabile. Non hai nemmeno bisogno di preoccuparsi di token di accesso -. Https si prende cura di questo per voi

Utilizzando http per ulteriori richieste sembra introdurre alcune vulnerabilità. Ora chiunque con uno sniffer di rete può intercettare il traffico rubare il token e spoof le vostre richieste. si può costruire una protezione per evitare che - crittografia di token, utilizzare una volta gettoni, ecc, ma in questo modo si sarà ri-creare https.

Tornando alla uomo https in mezzo l'attacco - è basata sulla capacità di qualcuno di inserirsi tra il server e il client e imbuto vostre richieste attraverso il loro codice. E 'tutto fattibile cioè nel caso in cui l'attaccante ha accesso alla rete fisica. Il problema come attaccante dovrà affrontare è che non sarà in grado di darvi un certifica digitali corretti - non ha la chiave privata utilizzata per firmare. Quando https si accede attraverso un browser, il browser ti dà un avvertimento, ma ancora in grado di farvi attraverso la pagina.

Nel tuo caso è il client che comunica con il server. E si può fare in modo che tutte le convalide corretto del certificato sono a posto. Se lo fai si dovrebbe andare bene

Modifica

Distacco Yishai - sì certo sovraccarico è coinvolto, in primo luogo della CPU, ma se questo ulteriore sovraccarico spinge il server fuori bordo, si hanno grossi problemi con la tua applicazione