Questo schema token API è abbastanza sicuro

Question

Questo schema token API è abbastanza sicuro

#1 da (6 voti)

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:

L'ID utente è codificato nel token (per ridurre lo stress sul DB)
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

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

Percorso protetto

L'utente invia la richiesta GET "/ users / me" con il set di token come Autorizzazione: intestazione Bearer
Il server verifica il JWT e invia le risposte all'errore appropriate se la verifica fallisce
Il server quindi interroga l'archivio Redis e verifica che l'uuid memorizzato per l'utente corrisponda al uuid codificato nel JWT
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?

rest authentication

posta Ross J 20.03.2014 - 11:41

fonte

1 risposta

Leggi altre domande sui tag rest authentication

Uso di sale per la sicurezza di primavera? Possiamo costruire un protocollo di scambio chiavi senza certificati?

score 6 · Answer 1

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.