Usa il token JWT per "ricordami" meno sicuro del token di sessione casuale?

7

Ho letto " link " e " link " (tra gli altri :-)) e cosa che vorrei evitare è usare ciecamente ogni misura di sicurezza I puoi pensare solo a sentire più sicuro. Qualcosa come hashing hash "just in case".

Quello che ho ora (il terzo giorno di passare attraverso l'esempio MEAN) - Ho token JWT (id dell'utente) + data di scadenza. Quindi il segno non vivrà per sempre. Questo token è memorizzato come cookie per ottenere la funzionalità "ricordami".

Quello che mi infastidisce qui è la mancanza di dati casuali che il server aggiunge al mix, così sicuro, non sicuro, ma è una configurazione molto deterministica (vedi il secondo articolo che ho linkato).

Quindi mi chiedo se il token JWT sia meno sicuro del token di sessione "classico" - sto pensando a tale impostazione:

  • login utente, il token JWT viene creato come prima, viene creato anche un token di sessione (id + numero casuale), l'hash del numero casuale è memorizzato nel DB (la data di scadenza è impostata ovviamente)
  • per lavoro normale viene utilizzato token JWT (non è usato per "ricordami")
  • il token di sessione viene utilizzato per "ricordami", è memorizzato come cookie

E quando l'utente ritorna, "ricordami" entra in gioco, invece di accedere, cookie con token di sessione viene utilizzato per autorizzare l'utente, in caso di successo, viene creato JWT.

Quindi ci sarebbero tre "livelli":

  • login + password - utilizzo infinito nel tempo
  • token di sessione ("ricordami") - uso a lungo termine
  • Token JWT - utilizzo a breve termine, solo per il lavoro corrente

La mia domanda è: il mio primo approccio con JWT è meno sicuro o meno? O in altre parole - l'aggiunta di "token di sessione" come descritto sopra ha reso questa installazione più sicura o solo più confusione? : -)

    
posta greenoldman 08.07.2016 - 20:55
fonte

2 risposte

7

Le JWT, se sottoposte a hash e crittografate con sufficiente forza, sono altrettanto sicure delle sessioni e riducono l'overhead. Assicurati di mantenerlo piccolo (anche se stai facendo qualcosa che richiede più di qualche KB di storage probabilmente stai facendo qualcosa di sbagliato ...). Segui le best practice per la sessione con JWT e starai bene.

Se utilizzi un algoritmo abbastanza potente e una chiave abbastanza potente, l'utente che tenta di crearlo sarà MODA sfortunato. E se lo fanno, devono anche trovare un modo per rubare i cookie JWT di altre persone per ottenere quelle informazioni (lo stesso tipo di attacco contro una sessione).

Se una JWT è meno sicura di una sessione, allora l'hai progettata in modo errato perché una JWT è una sessione lato client. Qui puoi salvare tutto ciò che memorizzerai in una sessione. Puoi anche memorizzare un ID di sessione al suo interno per tenere traccia di cose più grandi nel DB che non avrebbero un posto nel JWT.

    
risposta data 08.07.2016 - 21:07
fonte
7

Come ha detto Robert, un jwt può essere altrettanto sicuro di una sessione se è crittografato correttamente. Assicurati che il segreto che usi sia davvero unico.

ATTENZIONE: esiste una vulnerabilità con alcune librerie di token web di json che usano chiavi asimmetriche.

node-jsonwebtoken, pyjwt, namshi / jose, php-jwt o jsjwt con chiavi asimmetriche (RS256, RS384, RS512, ES256, ES384, ES512). Queste sono librerie vulnerabili e per risolvere assicurati di avere gli ultimi aggiornamenti per loro.

Questo sito Web è molto utile su jwt education e testing: link

Questa risposta di overflow dello stack spiega le chiavi asimmetriche e simmetriche: link

Questo è ciò che i pacchetti uso nella mia applicazione MEAN.    "jsonwebtoken": "^ 5.7.0",     "passport-jwt": "^ 2.0.0"

passport.js è per l'autenticazione

    
risposta data 08.07.2016 - 22:07
fonte

Leggi altre domande sui tag