'Ricordami' combinato con il token di autenticazione

Question

'Ricordami' combinato con il token di autenticazione

#1 da (3 voti)

8

Ho sviluppato un'applicazione client che parla su un'API REST a un server. Il modo in cui funziona l'applicazione è quello di inviare la coppia username / pwd nel login iniziale al server e quindi rispondere con un token di autenticazione sotto forma di GUID appena generato.

Il client utilizza il GUID per parlare con il server per il resto della sessione (per sempre finché la memoria locale non viene cancellata). La pagina di accesso richiede la possibilità di rimanere connessi. Per ottenere ciò, memorizzo il token GUID nella memoria locale. Se la chiave è presente, si registra automaticamente nell'app.

Tutte le comunicazioni avvengono su SSL, quindi non sono preoccupato per la sicurezza dei dati o del MITM, ma sono preoccupato per la sicurezza del token memorizzato nella memoria locale.

Alcune domande:

Dovrei crittografare ulteriormente il GUID? Questo mi dà qualcosa?
La memorizzazione del token di autenticazione GUID nella memoria locale è un grosso rischio per la sicurezza? Vale la pena assicurarsi?
La memorizzazione del token all'interno di un cookie migliora le cose?

Ho anche pensato che il server generasse nuovi token ogni nuovo accesso e riducesse la finestra di attacco, ma ciò impedirebbe il funzionamento della funzione "ricordami di me".

authentication cookies

posta jaffa 17.12.2013 - 17:53

fonte

1 risposta

Leggi altre domande sui tag authentication cookies

Incoerenze rilevate nelle intestazioni HTTP del provider OpenID. Qual è il più sicuro che dovrei imitare nel mio STS e Relying Party? Come gestire i diritti di amministratore per il personale dell'helpdesk?

score 3 · Answer 1

Quando si dice GUID è un GUID effettivo come da specifica, o una chiave generata casualmente corretta? Se non è casuale, questo è il problema più grande proprio lì perché la sicurezza della sessione ora si basa su qualcosa di molto facile da indovinare.

Dato questo, per rispondere alle altre domande devi chiederti: cosa stai proteggendo? cosa stai proteggendo contro? Che tipo di aggressori? Quanto impegno sei e / o disposto a inserire?

Quindi devi considerare che ciò che stai guardando è proteggere una chiave su un sistema client potenzialmente ostile. È possibile crittografare la chiave di sessione, ma con quale chiave? Quale algoritmo? Tutti i browser supportano gli algoritmi necessari? Come proteggi quella chiave? La maggior parte dei browser non supporta crypto, quindi questo complica molto le cose.

Memorizzare le cose nella memoria locale è migliore / peggiore / uguale alla memorizzazione in un cookie. Da un lato è meglio perché può aiutare a proteggere contro CSRF perché per ottenere l'accesso alla chiave di sessione che è necessario eseguire all'interno di un contesto che può accedere all'archivio locale, mentre un cookie sarà abbastanza bene essere inviato al server ad ogni richiesta finché il cookie è valido. Tuttavia, l'archiviazione locale non è mai stata pensata per memorizzare elementi sensibili come le chiavi di sessione, quindi non ha necessariamente la stessa protezione di livello di un archivio di cookie su una macchina (cronologia essendo quello che è, i cookie avevano lo stesso problema anche durante il giorno ). Al giorno d'oggi i cookie hanno anche una protezione contro l'accesso da JavaScript, quindi XSS non può fare cose divertenti con sessioni come spedire le chiavi su un altro server, mentre la memoria locale è accessibile solo da JavaScript.

Una possibile soluzione è quella di utilizzare sia un cookie che una memoria locale per creare una sorta di chiave composta, ma potrebbero esserci anche delle complicazioni.

Potresti anche aggiornare il token ogni tanto e assicurarti che sia invalidato sul server per impedire chiavi a lunga vita, ma questo non risolve necessariamente nulla se un utente visita ogni poche settimane.

Chiaro come fango?