Qual è il modo migliore per implementare "ricordami" per un sito Web? [chiuso]

510

Voglio che il mio sito Web abbia una casella di controllo su cui gli utenti possono fare clic in modo che non debbano accedere ogni volta che visitano il mio sito Web. So che dovrò memorizzare un cookie sul proprio computer per implementarlo, ma cosa dovrebbe essere contenuto in quel cookie?

Inoltre, ci sono errori comuni a cui prestare attenzione per impedire a questo cookie di presentare una vulnerabilità di sicurezza, che potrebbe essere evitato pur continuando a fornire la funzionalità "Ricordami"?

security cookies remember-me

— Vort3x
fonte

5

Controlla stackoverflow.com/questions/549/… (parte II della risposta principale)

— Frosty Z

se stai usando ASP.NET, controlla codeproject.com/Articles/779844/Remember-Me

— Believe2014

1

Ci sono alcune informazioni molto utili su Security SE ~ security.stackexchange.com/questions/19676/…

— b1nary.atr0phy

La risposta attualmente accettata da splattne è eccessivamente complessa. Creare un token +16 byte da un'origine casuale, l'hash e salvare l'id dell'account hash + nel database. Quindi inviare il token all'utente (codificato Base64) in un cookie HTTPS + httpOnly (quindi Javascript non può accedervi / rubarlo). In questo modo, nessuno può indovinare il token o disconnettere le persone con ipotesi non valide, ma anche se il tuo database è stato violato nessuno può usare i token nel database (sono hash). Quindi solo il client originale (o qualcuno che ruba il token dal browser store in qualche modo) può usarlo.

— Xeoncross

536

Best practice sui cookie di accesso persistenti migliorata

È possibile utilizzare questa strategia descritta qui come best practice (2006) o una strategia aggiornata descritta qui (2015):

Quando l'utente accede correttamente con Remember Me selezionato, viene emesso un cookie di accesso oltre al cookie di gestione della sessione standard.
Il cookie di accesso contiene un identificatore di serie e un token . La serie e il token sono numeri casuali indelebili da uno spazio adeguatamente ampio. Entrambi sono memorizzati insieme in una tabella di database, il token è sottoposto a hash (sha256 va bene).
Quando un utente non registrato visita il sito e presenta un cookie di accesso, l'identificatore della serie viene cercato nel database .
1. Se l' identificatore di serie è presente e l'hash del token corrisponde all'hash per quell'identificatore di serie, l'utente viene considerato autenticato . Viene generato un nuovo token , un nuovo hash per il token viene archiviato nel vecchio record e viene inviato all'utente un nuovo cookie di accesso (va bene riutilizzare l' identificatore di serie ).
2. Se la serie è presente ma il token non corrisponde, si presume un furto . L'utente riceve un avvertimento fortemente formulato e tutte le sessioni ricordate dell'utente vengono eliminate.
3. Se il nome utente e le serie non sono presenti, il cookie di accesso viene ignorato .

Questo approccio fornisce una difesa approfondita. Se qualcuno riesce a perdere la tabella del database, non offre a un utente malintenzionato una porta aperta per impersonare gli utenti.

— al 72%
fonte

20

vedi anche: stackoverflow.com/questions/549/… NON leggere la versione "migliorata"

— Jacco

8

Il problema è che si espone il nome utente nel cookie, anche se questo è ciò che fa Gmail. Perché hai bisogno sia di un ID serie che di un token? Un token più grande non andrebbe bene?

— Dan Rosenstark,

10

Inoltre, per quanto riguarda questo modello, ciò che impedisce a un utente malintenzionato di rubare e di posizionare il cookie sul suo computer e di eliminare il cookie dal computer compromesso. Il suo computer sarebbe stato autenticato e aggiornato secondo necessità senza che il computer hacker lo sapesse mai? L'unica modifica sarebbe che l'utente dei computer hackerati dovrebbe accedere nuovamente e impostare ricordami. Non è chiaro se l'utente compromesso lo riconosca o meno.

24

@HiroProtagonist L'identificatore di serie serve a prevenire un attacco DoS. Senza di essa, potrei scrivere rapidamente uno script che colpisce il tuo sito con ogni nome utente e un token non valido, disconnettendo tutti sul tuo sito.

— Chris Moschini,

6

Questa soluzione è SBAGLIATA, non gestisce la valuta: se arrivano contemporaneamente due richieste di autenticazione Ricordami, con lo stesso cookie Ricordami, la prima ha esito positivo e cambia il token, la seconda provoca un'autenticazione non tollerata e un falso allarme (perché il token è già stato modificato dalla prima richiesta). (Questa situazione può verificarsi all'avvio del browser e il sito viene ripristinato in due schede del browser.)

— Slobo

9

Vorrei memorizzare un ID utente e un token. Quando l'utente torna sul sito, confronta queste due informazioni con qualcosa di persistente come una voce di database.

Per quanto riguarda la sicurezza, non inserire nulla che consenta a qualcuno di modificare il cookie per ottenere vantaggi aggiuntivi. Ad esempio, non memorizzare i loro gruppi di utenti o la loro password. Tutto ciò che può essere modificato per eludere la tua sicurezza non deve essere archiviato nel cookie.

— 83%
fonte

8

Memorizza il loro UserId e un RememberMeToken. Quando effettuano il login con Remember Me selezionato, genera un nuovo RememberMeToken (che invalida tutti gli altri computer contrassegnati che sono ricordati di me).

Quando tornano, cercali con il token Remember Me e assicurati che UserId corrisponda.

— jonnii
fonte

Questo può essere forzato brutalmente in pochi secondi. Imposterò il mio user_id su 1 e forza bruta tutti i token. Mi darà accesso in pochi secondi

— Un amico il

4

Indagando me stesso su sessioni persistenti ho scoperto che semplicemente non vale il rischio per la sicurezza. Usalo se devi assolutamente farlo, ma dovresti prendere in considerazione una sessione del genere solo debolmente autenticata e forzare un nuovo accesso per tutto ciò che potrebbe essere utile per un attaccante.

Il motivo ovviamente è che i cookie che contengono la sessione persistente vengono rubati così facilmente.

4 modi per rubare i tuoi cookie (da un commento di Jens Roland sulla pagina @splattnebasato sulla sua risposta):

Intercettandolo su una linea non sicura (sniffing dei pacchetti / dirottamento della sessione)
Accedendo direttamente al browser dell'utente (tramite malware o accesso fisico alla casella)
Leggendolo dal database del server (probabilmente SQL Injection, ma potrebbe essere qualsiasi cosa)
Da un hack XSS (o simile exploit lato client)

— Jarl
fonte

104

1. HTTPS è progettato per impedire ciò. 2. Resta connesso qui non è il problema di sicurezza, hai problemi più grandi. 3. Come per 2. 4. Ciò può essere prevenuto dalla politica di controllo degli accessi e da una buona sanificazione degli input; se non esegui questi passaggi, hai di nuovo problemi più grandi rispetto a Resta connesso.

— Chris Moschini,