Il mio sistema di autenticazione senza sessione è sicuro?

Il tuo concetto di base non è nuovo: vuoi avere uno stato associato all'utente, ma non vuoi memorizzarlo da solo. Invece, lo memorizzi sul client (in un cookie). Dal momento che si desidera proteggere da alterazioni di tale stato (ad esempio un client che costruisce un cookie da zero), è necessario un controllo di integrità, come un Codice di autenticazione dei messaggi . La tua costruzione con una funzione hash è un MAC grezzo. Accade che sia un MAC debole con le solite funzioni di hash, a causa dell'attacco estensione di lunghezza .

Se vuoi un MAC, usane uno potente e questo significa HMAC . È standard e diffuso.

Naturalmente, l'archiviazione della chiave segreta (per i calcoli MAC) è un punto delicato. Qualcosa incorporato nel "codice sorgente" dell'applicazione esiste come un file, che (per sua natura) può leggere l'applicazione, rendendolo vulnerabile agli exploit che ottengono l'accesso illegale in lettura a file arbitrari. Sarebbe meglio (ma più difficile) fare in modo che il codice MAC possa essere ottenuto dinamicamente dall'applicazione tramite un protocollo di comunicazione locale (l'applicazione contatta un server locale, che fornisce la chiave solo all'applicazione); in questo modo, la chiave esisterebbe solo nella RAM dell'applicazione, non come un file leggibile con i diritti di accesso dell'applicazione. Non sarebbe una protezione assoluta (se il tuo server venisse completamente violato, beh, è così) ma sarebbe più strong nella pratica.

Vedo che includi la password con hash nei dati che sono MAC. Questo è un po 'strano; hai già il MAC come autenticazione: il MAC dimostra che i dati dei cookie sono autentici, quindi non c'è bisogno di ulteriori autenticazioni.

Blowfish non è una funzione hash; è un codice a blocchi (o un tipo di pesce ) e, come tale, non può essere utilizzato per l'hashing a meno che non sia considerevolmente modificato, il che significherebbe crittografia fatta in casa, e non è una buona idea.

Se stai scaricando lo stato sul client, potresti voler scaricare lo stato che il cliente stesso non dovrebbe conoscere. Ciò significa che potresti aver bisogno anche della crittografia. Combinare la crittografia e il MAC in modo sicuro non è così facile come sembra; ci sono modalità per questo . Raccomando EAX .

Ricorda che il non mantenimento dello stato ti rende intrinsecamente debole contro gli attacchi di replay . Questo è inevitabile. Puoi ridurre al minimo il danno utilizzando intervalli di validità brevi (ad esempio un cookie scade entro 15 minuti).

Questo sistema proposto è un gestore di sessione utilizzato per mantenere uno stato autenticato e il tuo metodo di creazione di token di sessione non è sicuro.

Ad esempio, usando SQL Injection puoi leggere la maggior parte dei dati segreti dal database. Se stai usando MySQL SQL Injection può essere usato per leggere i file usando la funzione load_file () che potrebbe essere usata per leggere il segreto da un file di configurazione.

In generale non si dovrebbe reinventare la ruota quando si costruisce un sistema. Sono certo che la tua piattaforma fornirà un gestore di sessioni sicure perché quasi tutte le applicazioni web ne avranno bisogno.

Gli ID di sessione dovrebbero essere puramente casuali e un pool di entropia come / dev / urandom è una scelta eccellente. Solo perché stai usando il gestore di sessioni della piattaforma non significa che sia configurato correttamente. Raccomando di leggere il foglio Cheat di gestione della sessione OWASP .

To make it sessionless, but making forging cookies not easy, this is the format of my cookies

Ciò che descrivi non è senza sessione: è solo che lo stato di autenticazione è conservato sul browser piuttosto che sul server.

Anche per un sito SSL solo è una buona idea provare a rilevare il dirottamento e la fissazione di sessione (per la fissazione il tipo di exploit disponibili sono più limitati poiché presumibilmente l'autenticazione è direttamente legata alla gestione delle sessioni) che significa memorizzare lato server dati.

L'autenticazione non è molto utile senza autorizzazione (per favore non dirmi che la tua autorizzazione è costruita direttamente nel tuo codice) che dipende ancora dalle informazioni conservate sul lato server.

Devi ancora rigenerare l'hash per verificare ogni richiesta o archiviare l'hash in una tabella di ricerca, il che significa recuperare i dati sul server.

Quindi, se hai qualche tipo di elaborazione dei dati, oltre ai dati transazionali, dovresti avere la prevenzione CSRF, che di solito viene implementata memorizzando il server dei dati.

Non vedo come hai ridotto il carico di lavoro rispetto all'utilizzo di una sessione web convenzionale. Se avessi semplicemente incluso il nome utente, il tempo di scadenza e un hash del nome utente e del tempo di scadenza, allora sì, potrebbe fare affidamento sul valore del cookie come prova equivalente dell'identità di una sessione web convenzionale - ma ciò consente solo un molto modello di autorizzazione / accesso limitato.