Questo metodo di gestione della gestione delle sessioni senza archiviazione è sicuro?

Question

Questo metodo di gestione della gestione delle sessioni senza archiviazione è sicuro?

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

0

Ho un'applicazione web in cui gli utenti possono accedere. A causa di vincoli tecnici, l'applicazione non è autorizzata a memorizzare alcuna informazione di sessione sul disco.

Per identificare le richieste dallo stesso utente senza memorizzare le sessioni su disco, ho ideato il seguente schema:

L'applicazione ha un lungo S segreto lato server generato casualmente, creato al momento dell'installazione. C'è un utente con un nome utente u e una password p .

Per accedere, l'utente presenta (u, p) all'applicazione web per l'autenticazione al tempo t . Se l'autenticazione ha esito positivo, invia un cookie c nella risposta, contenente Encrypt (u || t, S) . Encrypt in questo caso è AES-256 in modalità operativa CBC.

Successivamente, quando arriva una richiesta contenente c , l'applicazione decodifica il contenuto di c con S per ottenere u e t . Ovviamente, se u non è un utente valido, la richiesta viene respinta. Inoltre, la richiesta viene rifiutata se la differenza tra l'ora corrente e t è maggiore di x . Rifiutare la richiesta comporta chiedere al cliente di eliminare c e reindirizzare l'utente alla pagina di accesso.

Se l'utente invia una richiesta al momento t + y , ad esempio k < = y < = x , l'applicazione aggiorna c aggiornandolo a Encrypt (u || t + y, S) . k viene scelto come valore appropriato, come x / 3 .

La disconnessione implica semplicemente chiedere al browser di eliminare c .

Questo metodo di autenticazione è sicuro?

authentication cookies web-application session-management

posta user2064000 11.10.2017 - 17:00

fonte

2 risposte

Leggi altre domande sui tag authentication cookies web-application session-management

Qual è la logica per legare i certificati SSL a un nome di dominio? [duplicare] FooCoin, un BitCoin su uno smartphone con crittografia OS = imperfetto?

score 3 · Answer 1

Prima di tutto, come sempre, perché stai provando a tirare il tuo? Come indicato nei commenti, qualcosa come JWT svolge lo stesso lavoro.

Un breve sguardo suggerisce che questo dovrebbe funzionare. Anche se suggerirei di renderlo più trasparente. Potresti invece usare il valore del cookie -

username:[Username]&tokengeneratedat:[GenerationTime]&Sig:[Signature]

Questo rende lo sviluppo, il debug e l'ispezione degli utenti molto più semplici poiché i dettagli sottostanti sono in testo semplice. Questo approccio è anche più flessibile visto che puoi fare cose come le chiavi del ciclo: basta usare il tempo di generazione per identificare quale chiave usare.

Suggerirei di verificare che l'utente esista nella tabella almeno sull'aggiornamento del token / idealmente ogni richiesta per supportare revoca dell'accesso immediato.

score 1 · Answer 2

Lasciando da parte il vincolo un po 'assurdo e inspiegabile, il meccanismo è fondamentalmente ok finché non provi a memorizzare troppi dati nella sessione .

Ma come presentato è alquanto inefficiente e stai perdendo il vantaggio di scalabilità delle sessioni lato client - non hai incluso un meccanismo per verificare se il nome utente decrittografato è valido. Il controllo del timestamp fornisce una certa protezione, tuttavia, se fossi in me, includerei controlli aggiuntivi per convalidare che il testo in chiaro è qualcosa che è stato crittografato dal servizio, ad es. codifica e compressione json prima della crittografia e viceversa dopo la decrittografia.

Ho il sospetto che questo potrebbe essere più vulnerabile alla crittanalisi (l'autore dell'attacco può conoscere sia il testo chiaro che il testo cifrato) che in un'applicazione più convenzionale della crittografia simmetrica. Avresti bisogno di chiedere a qualcuno che conosce molto sulla crittografia. Ma questo sarebbe mitigato dall'uso appropriato dei vettori di inizializzazione e del padding casuale all'interno del testo in chiaro.