È sicuro usare il sale generato da bcrypt nel cookie per fungere da token al posto di una password?

Question

È sicuro usare il sale generato da bcrypt nel cookie per fungere da token al posto di una password?

#1 da (7 voti)
#2 da (4 voti)
#3 da (1 voti)

8

Ho un sito web (per hobby) che funziona solo su SSL. Il sito non si occupa di finanze, numeri di previdenza sociale o qualsiasi cosa di quel livello di importanza. Tuttavia, mi piacerebbe assicurarlo il più ragionevolmente possibile. I cookie sono contrassegnati come sicuri e httponly. Le password sono memorizzate sul lato server usando bcrypt.

Sto cercando di implementare "ricordami" per quegli utenti che vogliono usarlo. Leggendo questo sito, so che non vuoi memorizzare una password in un cookie; piuttosto, si desidera memorizzare un "token" che consente un utilizzo non critico, ma quindi richiedere la password effettiva per le azioni critiche (ad es., cambiare la password).

Invece di generare casualmente un token, quindi creare un database (o un altro metodo) di corrispondenza, è troppo insicuro usare il sale generato a caso da bcrypt come il token nel cookie?

I vantaggi sono:

Generato durante l'hashing della password, quindi nessun costo aggiuntivo o codice
Memorizzato con password, quindi può trovare e corrispondere se necessario
Unique

Gli svantaggi possono essere:

Il token non cambia da sessione a sessione

Se il cookie viene in qualche modo rubato, consente solo l'accesso non critico al sito. Cioè, non rivela la password attuale, la password non può essere cambiata, l'e-mail associata all'account non può essere cambiata.

Sto trascurando qualcosa di serio nello schema precedente?

passwords cookies salt bcrypt

posta RPW 29.09.2012 - 23:44

fonte

3 risposte

Leggi altre domande sui tag passwords cookies salt bcrypt

Crack plain RSA dato p, q ed e Come posso vedere i dettagli del traceroute in NMAP?

score 7 · Answer 1

I miei due centesimi, non stai trascurando nulla. Il tuo schema è corretto. Ma fai attenzione che quello che stai facendo non è sicuro. L'ID di sessione dovrebbe essere unico per ogni sessione. Perché potresti chiedere?

Supponiamo che un utente malintenzionato sia in grado di rubare il cookie. Quindi può accedere come tale utente. Fino a quando l'utente non si disconnette, poiché l'ID di sessione scade. Tuttavia, se l'ID della sessione rimane lo stesso per tutte le sessioni, l'utente malintenzionato potrà continuare ad accedere come utente, indipendentemente dal fatto che l'utente si disconnetta o meno.

In breve, ciò significa che una volta che un utente malintenzionato ha rubato un cookie, avrà una chiave permanente per le sessioni dell'utente (a meno che l'utente non modifichi la password). Realizza che questo è considerato un rischio elevato. L'impatto di un simile attacco può essere piuttosto alto.

score 4 · Answer 2

Non farlo.

Se un utente malintenzionato doveva annusare l'ID della sessione sul filo, l'utente malintenzionato ora ha effettivamente accesso permanente all'account dell'utente. Ugualmente come male, non hai modo di far scadere la sessione se fai sai che questo è successo dal momento che non puoi rigenerare il bcrypt digest senza avere la password dell'utente.

Non cercare di essere creativo. Generare un token casuale ad ogni nuova visita e rigenerarlo all'accesso per evitare attacchi di fissazione della sessione (laddove un utente malintenzionato imposta l'ID di sessione di un utente a un valore che conosce, quindi attende che l'utente effettui l'accesso prima di accedere al sito con tale ID) .

score 1 · Answer 3

Oltre alle risposte di cui sopra, trattando della necessità che i token di sessione siano casuali e diversi per ogni sessione, c'è anche un altro rischio nell'esporre pubblicamente il sale di un hash delle password.

Anche se è vero che un sale non vuole essere segreto, allo stesso tempo non è una buona idea renderlo noto pubblicamente. Questo perché un attacco che conosce il sale, può costruire una tabella arcobaleno per questo particolare salt , prima di ottenere una copia delle password con hash.

Quando ottiene la copia delle password hash (ad esempio con un attacco di SQL injection), può immediatamente tentare di cercare il valore dell'hash per cui ha già creato la tabella arcobaleno. Riducendo in tal modo il tempo che intercorre tra l'attacco e l'effettivo utilizzo dannoso dei dati rubati.

Polinomiale ha risposto a questo meglio di quello che posso .