Ricordami Cookie best practice?

Question

Sono rosso su 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.

i dati dei cookie stessi sono memorizzati nel DB al momento della creazione di cookie, e quando gli utenti hanno il cookie che viene comparato (i 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

Answer 1

è necessario memorizzare il user_id ed emettere un token casuale in aggiunta 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.).

fare attenzione che i gettoni non sono facili da indovinare (vale a dire che dovrebbe consistere di dati del tutto casuali, come da un CRNG).

Se si desidera fare un ulteriore passo avanti, è possibile crittografare 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 eseguire il rollover.

Answer 2

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

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

Answer 3

se i cookie vengono rubati, chiunque può accedere ai propri 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 impossibile.

Answer 4

Il "passaggio" a cui sembra che si dimentichi è che se il valore del cookie è correttamente sottoposto a hash, sarebbe di scarso valore per un utente malintenzionato.

EDIT:

Ecco un paio di cose che potete fare per proteggere gli utenti contro il furto di cookie attacchi correlati:

• gettoni Rigenerare nel corso del tempo, in modo che un attaccante non sarebbe 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.
• Mantenere e convalidare hash di user agents, in modo che un attaccante non sarebbe in grado di rappresentare un utente, a meno che lei ha sia il cookie e l'agente utente che dell'utente.

P.S. I cookie devono contenere token (casuali) e non hash password (vedi Hashes or tokens for "remember me" cookies?).

Answer 5

non avrei nemmeno memorizzare il nome utente in un cookie, solo un token casuale generato con un near impossible to crack technique e traccio che per l'utente nel database, e mai memorizzazione delle password dell'utente anche 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à compromessa 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à.

Answer 6

Il mio approccio è il seguente:

1. Hash la user_id
2. generare una chiave unica per l'utente - md5(current_timestamp)
3. Salva la chiave per il DB
4. Encode tutto in modo che appaia come un BS - base64
5. Salvalo nel cookie

Finora, ha funzionato benissimo per me :)

Answer 7

Non si deve MAI MAI memorizzare una password di utente in un cookie, nemmeno se è hash !!

Date un'occhiata a questo post sul blog:

• Improved Persistent Login Cookie Best Practice (Nov 2006; by bjaspan) (orignal)

Citazione:

1. Quando l'utente accede con successo con Ricordati di me controllato, un il cookie di accesso viene rilasciato in aggiunta 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 che non ha effettuato l'accesso visita il sito e presenta un cookie di accesso, il nome utente, la serie e il token vengono cercati nel database.
4. Se la terzina è 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 nome utente e serie non sono presenti, il cookie di accesso viene ignorato.