Ricordami Cookie best practice?

Ho letto molte vecchie domande su questo argomento e penso che la migliore pratica è quella di impostare un cookie con username , user_id e un token casuale.

Gli stessi dati sui cookie sono memorizzati nel DB durante la creazione di cookie e quando gli utenti hanno i cookie vengono confrontati (dati dei cookie, dati DB).

Sinceramente non riesco a capire dove sia la logica di sicurezza se questa è la vera best practice.

Un utente malintenzionato che ruba il cookie ha lo stesso cookie dell’utente originale: |

Hai dimenticato un passaggio? : P

È necessario memorizzare user_id ed emettere un token casuale oltre alla password dell’utente. Usa il token nel cookie e cambia il token quando la password cambia. In questo modo, se l’utente cambia la propria password, il cookie verrà invalidato.

Questo è importante se il cookie è stato dirottato. Sarà invalidato se l’utente rileva il dirottamento e inoltre, poiché il token non è correlato alla password, il dirottatore non sarà in grado di derivare e quindi modificare la password dell’account dell’utente e “possedere” l’account (presupponendo che sia richiesta la password esistente prima di cambiare la password, il dirottatore non possiede l’account e-mail in modo che non possano usare “Hai dimenticato la mia password”, ecc.).

Fai attenzione che i token non siano facilmente ipotizzabili (cioè dovrebbero consistere in dati del tutto casuali, come da un CRNG).

Se vuoi fare un ulteriore passo avanti, puoi criptare il cookie prima di inviarlo e decrittarlo al momento del ricevimento. Inoltre, non dare per scontato che un dirottatore non conosca la chiave di crittografia utilizzata, quindi convalidare il contenuto del cookie dopo la decrittografia.

Ma tutto ciò detto, preferisce utilizzare la gestione persistente delle sessioni di una libreria invece di far girare il proprio.

Non dovresti MAI MAI memorizzare la password di un utente in un cookie, nemmeno se è un hash !!

Dai un’occhiata a questo post del blog:

  • Best Practice Persistent Login Cookie Best Practice (novembre 2006; bjaspan) (originale)

Citazione:

  1. Quando l’utente effettua il login con Remember Me selezionato, viene emesso un cookie di accesso oltre al cookie di gestione della sessione standard. [2]
  2. Il cookie di accesso contiene il nome utente dell’utente, un identificatore di serie e un token. La serie e il token sono numeri casuali non percettibili da uno spazio adeguatamente grande. Tutti e tre sono memorizzati insieme in una tabella di database.
  3. Quando un utente non loggato visita il sito e presenta un cookie di accesso, il nome utente, la serie e il token vengono cercati nel database.
  4. Se la tripletta è presente, l’utente è considerato autenticato. Il token utilizzato viene rimosso dal database. Viene generato un nuovo token, memorizzato nel database con il nome utente e lo stesso identificatore di serie e un nuovo cookie di accesso contenente tutti e tre viene rilasciato all’utente.
  5. Se il nome utente e le serie sono presenti ma il token non corrisponde, si presume un furto. L’utente riceve un avvertimento fortemente scritto e tutte le sessioni memorizzate dell’utente vengono eliminate.
  6. Se il nome utente e la serie non sono presenti, il cookie di accesso viene ignorato.

Non memorizzerei nemmeno il nome utente in un cookie, solo un token casuale generato con una tecnica quasi imansible da decifrare e mapparlo all’utente nel tuo database, e non memorizzare mai la password dell’utente nemmeno hash in un cookie, sarà aperto a Brute Force Attack . Sì, se qualcuno ruba il token può accedere all’account dell’utente ma la password non sarà compromise e il token sarà invalidato non appena l’utente reale si disconnette. Ricorda inoltre che non dovresti consentire attività delicate come la modifica della password a un utente che ha solo un token valido, è necessario chiedere nuovamente la password per tali attività.

se i tuoi cookie vengono rubati, chiunque può accedere ai tuoi account. è in realtà ciò che fa il fuoco. la sicurezza sta nel token casuale. l’intero sistema presume che i cookie non possano essere rubati. l’unico altro modo per entrare è indovinare il token casuale. se lo fai abbastanza a lungo dovrebbe essere quasi imansible.

Il “passo” che ti sembra di dimenticare è che se il valore del cookie è correttamente hash, sarebbe di un piccolo valore per un utente malintenzionato.

MODIFICARE:

Ecco un paio di cose che puoi fare per proteggere i tuoi utenti dagli attacchi relativi ai furti di cookie:

  • Rigenerare i token nel tempo, in modo che un utente malintenzionato non sia in grado di impersonare un utente a meno che non abbia un cookie abbastanza recente. Se la sicurezza è la priorità, rigenerare i token su ogni richiesta (caricamento della pagina). Se non lo è, rigenerare i token al cambio della password.
  • Conserva e convalida gli hash degli agenti utente , in modo che un utente malintenzionato non sia in grado di impersonare un utente a meno che non abbia sia il cookie che l’agente utente quello dell’utente.

ps I cookie devono contenere token (casuali) e non hash password (vedi Hash o token per i cookie “ricordami”? ).

Ho sempre saputo che la funzione “ricordami” ha solo convertito il cookie di sessione (ovvero il cookie con l’ID di sessione) dallo scadere quando si chiude il browser a una data futura, non comporta il salvataggio di dati aggiuntivi, ma l’estensione della sessione.

E sì, se un utente malintenzionato ottiene il cookie, può impersonare l’utente. Ma questo è sempre valido e non ha nulla a che fare con “ricordami”.

Il mio approccio è il seguente:

  1. Hash the user_id
  2. Genera una chiave univoca per l’utente – md5(current_timestamp)
  3. Salva la chiave nel DB
  4. Codifica tutto così sembra un BS – base64
  5. Salvalo nel cookie

Finora, ha funzionato benissimo per me 🙂