Collegamenti magici: JWT vs stringa casuale

Question

I tutorial che ho incontrato sull'implementazione dell'autenticazione del collegamento magico (in Node) raccomandano un meccanismo come questo:

1. l'utente raggiunge il tuo endpoint con il proprio indirizzo email
2. generi un JWT firmato dall'email e dalla data usando una chiave costante (se sei un po 'più esperto, usi lo RS256schema asimmetrico invece di quello simmetrico HS256usato nella maggior parte dei tutorial (essendo l'impostazione predefinita credo))
3. invia l'email con il token come parametro di query
4. l'utente fa clic, l'endpoint viene colpito, si verifica il JWT, quindi l'email e la data all'interno

Mi scuso per la domanda sul cervello forse molto piccola , ma perché in realtà abbiamo bisogno di hashing o crittografia qui?

1. Non sarebbe più prudente generare semplicemente una stringa grande (come 50 caratteri), unica, casuale, alfanumerica (chiamiamola LURA) quindi memorizzarla, l'email e la data e inviarla all'utente? Quando gli endpoint di verifica vengono colpiti, possiamo dire: "yepp, ho quella cosa in archivio e l'ho pubblicata 2 minuti fa, via" . Lo scopo dell'utilizzo di JWT sarebbe quello di verificare che sono stato io a creare il token (con la mia chiave), ma posso anche verificarlo se vedo solo se ho la LURAstringa su file, giusto? Inoltre, JWT ha problemi . Ho la sensazione che JWT fosse destinato ad essere utilizzato quando la macchina che lo convalida è diversa da quella che lo rilascia e che il suo utilizzo in questo caso è dannoso per la sicurezza.

2. Domanda bonus : ho letto più volte sulla crittografia delle password , che SHA256è troppo debole nel 2020 e che si dovrebbe scegliere Argon2. Perché allora è RS256una buona scelta se è "da intendersi come SHA 256 con chiavi RSA 2048 bit".

Answer 1

Non sarebbe più prudente generare solo una grande ... stringa

Sì, lo sarebbe. Un token è spesso una soluzione semplice ed è più facile da ottenere. Le soluzioni crittografiche spesso presentano insidie ​​o devono essere implementate in modo totalmente corretto per essere sicure. I gettoni casuali sono più sicuri perché sono più semplici.

I JWT sono particolarmente utili quando si hanno più sistemi: se un sistema fornisce il token per accedere a un altro sistema e non hanno accesso allo stesso database.

SHA256 è troppo debole nel 2020

SHA256 è ancora considerata una funzione hash generica e sicura. Il problema è che le funzioni hash generiche non sono adatte per crittografare le password, poiché sono troppo veloci. Poiché un normale computer può calcolare miliardi di hash SHA256 al secondo, è possibile violare la password utilizzando miliardi di tentativi al secondo.

Tuttavia, in JWT, SHA256 non viene utilizzato per le password ma per l'integrità del messaggio, quindi non è un problema che sia veloce. Non c'è niente da indovinare.

Answer 2

È vero che puoi usare una stringa casuale per il collegamento magico e funzionerà perfettamente. Tuttavia, ci sono alcuni vantaggi nella scelta di implementarlo utilizzando JWT:

1. La convalida JWT non richiede una chiamata al database. Questo è forse il principale vantaggio dell'utilizzo di JWT. A seconda del numero di utenti, ciò può significare una significativa differenza di prestazioni.
2. È più facile integrarsi con i meccanismi di accesso esistenti come i provider di identità (possibilmente di terze parti) che già gestiscono la creazione / verifica / archiviazione dei token. Ciò è utile, ad esempio, se la tua applicazione utilizza già i token per accedere agli utenti con la tradizionale combinazione nome utente / password e desideri aggiungere collegamenti magici come opzione aggiuntiva.

Per quanto riguarda la tua domanda sugli algoritmi, per RS256 / HS256 in JWT lo scopo non è la crittografia ma la firma . I requisiti dell'algoritmo per la crittografia e la firma sicure sono diversi (e ancora più diversi se si parla di hashing della password).

Come nota aggiuntiva, il motivo per scegliere tra RS256 e HS256 è se intendi o meno consentire ad altri di verificare il tuo token.

Per RS256 si crea una coppia di chiavi pubblica / privata. Generi la firma utilizzando la chiave privata mentre una terza parte può verificare un token che hai creato utilizzando la tua chiave pubblica. Per HS256 la chiave per la firma e la verifica è la stessa, quindi normalmente la mantieni segreta, il che significa che solo tu puoi verificare il token.