La mia progettazione del sistema di persistenza di autenticazione è sicura?

Questo sistema è per un caricamento di file personali e per la condivisione di applicazioni Web realizzate con PHP.

Quando un utente accede all'applicazione, ha la possibilità di "rimanere connesso" dopo aver chiuso e riaperto il browser, proprio come la maggior parte delle altre applicazioni web. Ciò che effettivamente fa è che imposta un cookie HTTP, denominato auth , con una scadenza di 90 giorni sul browser client che contiene una stringa nel seguente formato: UserIdentifier:SeriesNumber:Token dove : è il delimitatore. Gli stessi dati sono anche mantenuti nella tabella del database user_auths , ma il token sarà sottoposto a hash prima che lo sia.

Il UserIdentifier è l'identificatore dell'utente dell'utente che ha scelto di rimanere connesso, il SeriesNumber è un numero casuale generato tra 0 e 2147483647 (incluso) e il Token una stringa casuale di 60 caratteri generata in ordine alfabetico , caratteri numerici e simbolici. Un valore di esempio potrebbe essere: 1:902449381:j7j]fP%CxIzcKSg/'wG]XzJd.OsX8"K0FlY')xXQz.5.Q]+KJnXi<>p/t7nz

Ogni volta che un utente visita l'applicazione ed è non trovato nella sessione HTTP, io:

1. Prova a trovare il cookie auth sul browser client. Se viene trovato, controllo se il valore di esso contiene due % delimitatori di: (controllando il formato corretto), se non viene trovata la quantità corretta di delimitatori, elimino il cookie del browser client e l'utente è non autenticato.

2. Se viene superato il test precedente, userò l'identificatore utente per cercare nella tabella db se l'utente dell'identificatore specificato ha qualsiasi righe nella tabella (nel senso che l'utente < em> ha ha scelto di "rimanere connesso" su uno o più browser). Se l'identificatore utente è non trovato nella tabella, elimino il cookie del browser client e l'utente è non autenticato.

3. Se viene superato il test precedente, ora utilizzerò sia il codice identificativo utente che per verificare la presenza di una riga corrispondente nella tabella db. Se trovato, verificherò il token cleartext dal cookie con il token hash dalla corrispondente riga corrispondente. Se non viene trovato o il token non viene verificato, presumo che si sia verificato un furto di cookie O il valore del cookie è stato manipolato. Invalido / Elimina TUTTI i dati di persistenza dell'autenticazione di questo utente in modo che non "rimangano più accesso" sul browser ANY che ha scelto e non autenticato.

4. Se il cookie ha superato il test precedente, significa che il cookie ei suoi dati erano validi e l'utente è considerato autenticato. Io rigenera l'identificatore di sessione e metto l'utente nella sessione. Genero un token nuovo , un hash e lo aggiorno nella riga della tabella corrispondente e rilascio al browser dell'utente un nuovo cookie auth con lo stesso identificativo utente, il numero di serie e la data di scadenza ma con il nuovo token ( versione cleartext).

Tutto questo viene elaborato per per ogni richiesta. Per ogni browser il processo è identico. Un utente può scegliere di "rimanere connesso" su più browser che desidera e avrà anche la possibilità di invalidare tutti gli accessi persistenti del proprio account.

Per terminarlo, ho uno script che controlla la tabella db ogni N minuti per le righe più vecchie poi 90 giorni e li elimina per mantenere la tabella pulita e invalidare gli accessi persistenti degli utenti dopo la scadenza .