Il sistema di autenticazione del servizio REST è sicuro?

Naviga le tue risposte
2

Devo implementare un'autenticazione basata su token per un servizio web RESTful. Questa è la prima volta che implemento funzionalità di sicurezza in un software, e questo è quello che ho in mente per ora:

  1. Il client prima autentica tramite un modulo di accesso (nell'applicazione client) con la sua e-mail e password.
  2. Se l'autenticazione ha successo, l'utente riceverà in risposta una chiave privata (generata casualmente) e un token (stringa - generata casualmente?). Il server memorizzerà nella db (o forse una cache?) Una tupla con i seguenti campi (email, chiave privata, hashedToken, scadenza del token), dove hashedToken è il valore dell'HMAC calcolato sul token, con chiave privata .
  3. Il client memorizza la chiave privata ricevuta e il token (in memoria).
  4. Per ogni richiesta futura, il client includerà in un'intestazione personalizzata (ad esempio authToken) il valore dell'HMAC calcolato sul token, con chiave privata e l'e-mail dell'utente (in un'altra intestazione) e sostituirà il token memorizzato in memoria con il token appena generato.
  5. Quando il server riceve la richiesta, controlla la tupla matematica dell'indirizzo email, controlla se il token memorizzato e il token ricevuto sono uguali e se il token non è scaduto. Se è ok, il server aggiorna la data di scadenza della tupla e il campo hashedToken è impostato sul valore di HMAC calcolato sul vecchio token, con chiave privata. il server elabora quindi la richiesta. (nessun intestazione di autenticazione aggiuntiva o informazioni incluse nella risposta)

I passaggi 1 e 2 utilizzeranno HTTPS. Altre richieste verranno inviate da HTTP, dal momento che un nuovo token viene generato dopo ogni richiesta di successo (il sniffing del token sarebbe inutile per un utente malintenzionato, penso).

Vorrei sapere quali sono i problemi con questo protocollo di autenticazione e come potrebbe essere migliorato.

Inoltre, questo approccio sarebbe più veloce del semplice includere l'e-mail e la password in un'intestazione in ogni richiesta e utilizzando HTTPS?

    
posta Sbiera Bogdan 26.08.2013 - 10:41
fonte

2 risposte

2

La risposta di base è: usa semplicemente HTTPS e autenticazione di base . Questo è molto più semplice. Il sovraccarico di HTTPS è lieve:

  • Un paio di roundtrip extra quando viene stabilita una nuova connessione. Ma le connessioni vengono mantenute in vita tra client e server e chiuse solo quando non vengono utilizzate per troppo tempo, quindi non dovrebbe importare molto. Infatti, una soluzione HTTPS pura potrebbe essere più veloce del tuo mix HTTPS / HTTP perché potrebbe funzionare su una singola connessione per l'intera procedura.

  • Alcuni overhead di rete, circa lo 0,2% per i dati di massa (intestazione e padding del record SSL e MAC); ancora una volta, questo si mostrerà a malapena sulle misure, figuriamoci sulla materia.

  • Alcuni sovraccarichi della CPU, ma molto meno del solito. Un core CPU di base può crittografare e decrittografare i dati a più di 100 MB / s, anche senza utilizzare AES-NI .

Se fai vuoi usare HTTP (dopo una fase HTTPS iniziale), allora devi tenere conto dei problemi di riservatezza e integrità. I tuoi giochi HMAC possono aiutare con l'integrità, ma impediscono attacchi di replay solo fino a quando il server ricorda l'ultimo "token value" (o il suo hash). Questo è stato e contraddice il punto di REST .

    
risposta data 26.08.2013 - 16:48
fonte
0

Questo approccio è vulnerabile agli attaccanti di Man In The Middle.

Un utente malintenzionato rileverà la fase iniziale HTTPS, quindi ogni richiesta intercettata dall'attaccante potrebbe rubare un token valido se la richiesta non viene inoltrata al server legittimo.

È necessario utilizzare il contenuto della richiesta REST quando si calcola l'HMAC per evitare di assegnare token senza restrizioni all'attaccante.

    
risposta data 26.08.2013 - 19:12
fonte

Leggi altre domande sui tag

Genera CSR con 2 nomi OU Wireshark rileva i messaggi sospetti tramite il protocollo jabber, dice che proviene dal mio sito web, non ha idea di cosa sia