Questo schema token API è abbastanza sicuro

4

Sto progettando un REST Api per un'applicazione mobile e ho qualche problema nel proteggere in modo appropriato l'accesso agli account.

Sto scrivendo il server API in nodeJS e verrà utilizzato principalmente da un client mobile (anche se un client Web potrebbe essere aggiunto in futuro)

Ci sono due aspetti principali che desidero includere nel processo di autenticazione:

  1. L'ID utente è codificato nel token (per ridurre lo stress sul DB)
  2. L'utente può avere solo 1 token valido in qualsiasi momento (l'accesso annulla qualsiasi token precedente)

Ecco il mio progetto iniziale (tutti gli endpoint sono su SSL):

Accedi

  1. L'utente POST è il suo nome utente & password per "/ login"
  2. Il server verifica che gli utenti esistano e la password corrisponde all'hash di bcrypt nel Db
  3. Il server genera uuid v4 per l'utente e lo memorizza in Reds con l'ID utente come chiave
  4. Gli utenti uuid e l'ID utente vengono quindi codificati in un token Web Json con una scadenza di 1 settimana
  5. Il JWT viene quindi inviato agli utenti come token di autenticazione

Percorso protetto

  1. L'utente invia la richiesta GET "/ users / me" con il set di token come Autorizzazione: intestazione Bearer
  2. Il server verifica il JWT e invia le risposte all'errore appropriate se la verifica fallisce
  3. Il server quindi interroga l'archivio Redis e verifica che l'uuid memorizzato per l'utente corrisponda al uuid codificato nel JWT
  4. Se gli uuid corrispondono all'id utente è impostato su req.user e la richiesta viene elaborata, in caso contrario viene inviato un messaggio di errore

Questa sembra una buona strategia di autenticazione o sono lontana?

    
posta Ross J 20.03.2014 - 11:41
fonte

1 risposta

6

Trovo due possibili difetti.

Gli UUID in generale non garantiscono di essere casuali crittografici. A seconda dell'implementazione, è possibile fornire un'ipotesi qualificata su quali altri UUID sono stati generati da un generatore, dati alcuni degli output. È necessario utilizzare una lunghezza adeguata di output da un generatore di numeri casuali crittografico come token di sessione.

Ogni volta che estendi a un client web devi assicurarti contro la falsificazione di richieste cross site, cioè qualsiasi richiesta che modifica i dati sul server deve avere un token che non è un cookie come parte della richiesta, altrimenti la richiesta può provenire da un altro sito Web aperto sul computer degli utenti.

Un'altra cosa, se si vuole ridurre lo stress sul DB, è possibile memorizzare le informazioni di sessione nella memoria di processo nel nodo. Hai solo bisogno del database per le cose che devono persistere in caso di arresto anomalo.

    
risposta data 20.03.2014 - 13:54
fonte

Leggi altre domande sui tag