Hash la chiave di firma di un token di autenticazione nel database

0

Ho clienti che sono tutti i browser. Tutti i client eseguono il rendering di una sola applicazione per ottenere dati da un'API Web. Il design dell'API segue i principi REST.

Uso l'autenticazione basata su token senza OAuth perché non ho terze parti per la mia API e voglio sentire in che modo la sicurezza può danneggiare la mia mente; -)

Il formato del mio token I è JSON Web Token (JWT): contiene userId, lifetime (data di scadenza), emittente e chiave di firma (alg: HS256 che è hash SHA-256 algo)

Il token è valido 7 giorni. Quindi l'utente deve riautentarsi ogni 7 giorni. (Forse non è ancora la soluzione finale in questo campo ...)

Questo è il mio flusso di autenticazione:

1) Uso l'autenticazione di base su SSL per il mio endpoint di accesso

2) Se il nome utente e la password inviati dall'utente sono validi, inserisco un token nella risposta

3) Questo token è memorizzato nella memoria locale / di sessione sul lato client

4) Ogni ulteriore richiesta a un endpoint di risorsa dell'API del server deve includere un token valido altrimenti la richiesta ottiene un 401 e vede di nuovo la vista di accesso.

5) Prima di svolgere ulteriori indagini con il token come controllare la data di scadenza, devo sapere se l'autenticità del token è ancora valida o se un utente legittimo lo ha modificato. Ciò presuppone che il token sia stato firmato con una chiave prima della quale chiamiamo MAC (Message Authentication Code)

Convalidare il token con la stessa chiave di firma il token è stato firmato durante la creazione del token. Conservo la chiave di firma che è un gruppo di numeri generati casualmente nella tabella sql dell'utente che appartiene all'ID utente. L'utente che ottengo dal token vede sopra. O meglio detto, memorizzo l'hash della chiave (array di byte) nella tabella sql dell'utente con hash con BCrypt.

Domanda :

  • C'è qualcosa che non va?

  • Devo memorizzare il token completo nel database invece della sola chiave di firma e qual è il vantaggio?

posta Elisa 09.02.2014 - 22:56
fonte

1 risposta

1

Sul tuo primo punto, ci sono alcuni potenziali aspetti negativi e punti a usare l'autenticazione di base su SSL che potresti voler prendere in considerazione.

  • Se utilizzi l'autenticazione di base, la tua soluzione basata su token potrebbe non essere realmente necessaria poiché, una volta che un browser ha inviato le credenziali di autenticazione di base, in primo luogo le invierà di nuovo con ogni richiesta a tale ambito, così potresti basta controllarli di nuovo e non preoccuparsi del token:)
  • L'autenticazione di base invia le credenziali dell'utente in formato codificato tramite il collegamento, chiunque può vedere i dati in transito può ottenere i crediti. Ovviamente SSL fornirà ovviamente una certa protezione, ma in alcuni casi presenta comunque un certo rischio. Potresti voler consultare autenticazione digest se persi questo schema di autenticazione
  • Di per sé l'autenticazione di base non include alcune protezioni di autenticazione che potrebbero lasciare l'applicazione aperta agli attacchi. Ad esempio non c'è blocco degli account, nessun requisito di qualità della password, nessuna funzionalità di disconnessione, nessuna funzionalità di modifica della password e nessuna protezione contro l'utente che ha più accessi simultanei.
risposta data 10.02.2014 - 08:42
fonte

Leggi altre domande sui tag