Non capisco cosa c'è che non va usando solo i cookie per l'autenticazione?

Question

Non capisco cosa c'è che non va usando solo i cookie per l'autenticazione?

#1 da (4 voti)
#2 da (3 voti)
#3 da (0 voti)

9

Sto scrivendo un app-server e c'è un'opzione per usare semplicemente i cookie sicuri per l'autenticazione. Ecco come sembra funzionare:

Si definisce una chiave segreta di 32 byte sul server
Quando l'utente esegue il login, controlli il database per vedere se gli hash di bcrypt corrispondono, e in tal caso chiami request.remember(user_id)
Sui gestori di percorsi che richiedono l'autenticazione (e l'id_utente), si disfa l'user_id decifrando il cookie e se è valido, si continua. Altrimenti, restituisci un errore Unauthorized .
Se un utente preme il gestore di logout, chiamo request.forget() e il cookie viene eliminato sul client.

Tutto sembra funzionare. Quindi quello che mi interessa è perché non tutti lo fanno? Mi guardo intorno e sembra che parli molto di JWT, che generi UUID di token di autenticazione e li memorizzi in Redis / nel database, ecc. Quindi, a quanto pare, questo metodo non è sicuro? E hai bisogno di memorizzare lo stato sul server?

Se dovessi indovinare, direi che un problema con questo approccio potrebbe essere che se il cookie viene rubato in qualche modo (non è sicuro come da quando è tutto su TLS ei cookie sono HTTP-Only e Secure se questo è importante), quindi l'utente sarebbe in grado di essere impersonato da un utente malintenzionato. Ma penso che questo si applicherebbe anche agli altri schemi?

Un altro problema che ho riscontrato è che un utente può generare in modo casuale token di autenticazione fino a quando ne ha trovato uno che corrisponde a un utente? Ma non sono sicuro che questo sia un problema dato che valuterò il limite del gestore di autenticazione e immagino che questo genere di cose richiederebbe un po 'di tempo? Oh, forse potrebbero creare 100 account e vedere a cosa assomigliava il token dell'autenticazione cookie crittografato e applicarlo bruteforce sul lato client per scoprire qual era la chiave segreta sul server? E poi sarebbero in grado di impersonare gli utenti generando token di autenticazione? Anche se penso che ci vorrà troppo tempo per trovare la chiave dato che sono 32 byte?

Suppongo che questo approccio non faccia scadere automaticamente i cookie (è questo il motivo per cui questo non viene usato molto? Ma penso che ci sia un modo per aggiungere un'intestazione di scadenza ai cookie? Sarebbe un lavoro?) Non sono nemmeno sicuro se Ho bisogno di scadenza per questa app .. Sembra che possa infastidire gli utenti. Quanto durano le sessioni in luoghi come Google / Facebook? Mi sento come se fossi sempre connesso a quei servizi per sempre.

Non lo so. Mi sento come se mi mancassero molte informazioni qui. C'è un posto dove posso trovare un elenco di pro e contro di tutti questi approcci diversi?

api authentication encryption cookies web-application

posta Chron Bag 16.10.2018 - 00:33

fonte

3 risposte

Leggi altre domande sui tag api authentication encryption cookies web-application

Usa il tracciamento WiFi per identificare i ladri Perché una "tela contaminata" è un rischio?

score 4 · Answer 1

Lo schema che descrivi è potenzialmente vulnerabile alla falsificazione di richieste cross-site (CSRF).

È possibile effettuare una richiesta dannosa per conto dell'utente. Questa richiesta invierebbe il cookie che supererebbe i controlli di autenticazione ed eseguirà tutte le attività che l'utente potrebbe effettuare autonomamente.

link

Se si guarda il link sopra all'articolo OWASP su CSRF, esso specifica in modo specifico i cookie segreti come tecnica di attenuazione non valida.

score 3 · Answer 2

Supponendo che tu stia utilizzando i tuoi cookie come identificatore di autenticazione stateless, lo schema è fondamentalmente simile a JWT tranne che con i cookie. Le principali differenze sono:

Le JWT in genere vengono firmate solo al posto di quelle crittografate (sebbene sia possibile crittografarle). Ciò significa che puoi chiedere a servizi di terze parti di creare token per te. Ciò consente di collegare la tua applicazione ad altri servizi di autenticazione o fornire tu stesso un servizio di autenticazione per altre app.
Le app e i cookie nativi mobili potrebbero creare problemi. Generalmente può essere superato, ma l'implementazione può essere molto più complicata rispetto all'utilizzo di token che devono essere semplicemente allegati come testo a un'intestazione o a un corpo di richiesta e possono essere facilmente archiviati.
Le JWT sono più facili da utilizzare specialmente in ambienti javascript, in quanto puoi attaccare praticamente tutti i metadati che desideri alle rivendicazioni e puoi leggerli come faresti con il normale JSON. Aiuta anche che con la loro popolarità è possibile trovare soluzioni già pronte per altri framework moderni.
I cookie sono vulnerabili alla falsificazione di richieste tra siti (CSRF), mentre i token dipendono dal modo in cui vengono archiviati (cross-site scripting (XSS) se nella memoria Web, CSRF se si decide sul cookie di archiviazione).

In sintesi ciò che stai suggerendo è solido, ma è fondamentalmente lo stesso di JWT che manca alcuni dei vantaggi. Se il tuo sistema non ha bisogno di integrazione con terzi, allora con tutti i mezzi vai con i cookie, ma assicurati di proteggerli contro CSRF come menzionato da @Daisetsu.

score 0 · Answer 3

Hai quasi ragione. Il cookie è crittografato, quindi il contenuto non può essere visto o incasinato. (A meno che la crittografia non funzioni.) Il cookie viene inviato solo su TLS, quindi non può essere rubato da un MITM. (A meno che la tua cert non sia compromessa in qualche modo.) Il cookie è impostato su Solo HTTP, quindi non può essere rubato da alcun JS dannoso. Da tutti gli angoli che hanno senso, è sicuro.

Ho solo un problema con il tuo setup. Stai utilizzando un identificatore persistente per l'utente in quel cookie. Nel caso improbabile che qualcosa vada storto, il compromesso durerà per tutta la durata del record dell'utente. Genera una stringa casuale, memorala e usala per fare riferimento al tuo utente. In questo modo, ricicli costantemente ciò che identificerebbe un utente, contenendo qualsiasi violazione alla durata della sessione.

Considera anche l'apertura di quadri popolari e lo studio di come gestiscono ciò. Puoi raccogliere alcune tecniche utili per rendere le cose ancora più sicure o più efficienti.

Per quanto riguarda le JWT e simili, c'è una miscela di esse che è il nuovo splendore che le persone vogliono usare e sono una tecnica veramente utile per fare in modo che l'autenticazione esista su un sistema separato rispetto a dove l'utente deve essere autenticato.

Modifica: ho fatto un piccolo tuffo in Laravel per vedere come lo fanno. Memorizzano l'ID utente nella sessione. La sessione è lato server e quindi sicura. Questo lo separa dalla gestione della sessione, che sembra corretta. L'identificatore di sessione è una stringa casuale di 40 caratteri. Questo viene impostato come solo HTTP.