2011-12-14 9 views
6

Sto cercando di implementare un "ricordi di me" caratteristica, seguendo le indicazioni fornite qui: The definitive guide to form-based website authentication, e qui: http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/Il modo migliore per hashing un "ricordati di me" cookie di token

Sembra che il " cookie token "deve essere sottoposto a hash quando archiviato in DB (se un utente malintenzionato ha accesso al DB, i token unhashed hanno l'aspetto di semplici login/password, consentendo l'accesso al sito Web).

ricerca di un buon algoritmo di hashing, ho trovato questa tecnica consigliata utilizzando bcrypt: https://stackoverflow.com/a/6337021/488666

ho provato e scoperto che con la quantità di giri proposto (15) porta ad una molto tempo di elaborazione lento (hash 2,3s + verifica 2,3s su Intel Core 2 Duo E8500 + 4 GB RAM)

So che gli algoritmi di hashing dovrebbero essere relativamente lenti per ostacolare gli aggressori, ma a quel livello, ostacola utenti di utilizzare il sito Web :)

Pensi che meno colpi (ad es. 7, che riduce il tempo di elaborazione a 10 ms + 10 ms) sarà sufficiente?

+0

possibile duplicato di [Qual è il modo migliore per implementare "ricordami" per un sito web?] (Http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement- remember-me-for-a-website) – symcbean

+0

L'uso di un hash è una perdita di tempo molto dispendiosa per questo: utilizzare un valore casuale – symcbean

+0

Documenti/articoli anwser/articoli consigliabili per hash il token nel DB; Sto semplicemente cercando consigli su un modo appropriato per farlo. –

risposta

13

Citando The definitive guide to form-based website authentication:

Non conservare il cookie di accesso persistente (token) nel database, SOLO un hash di esso! Il token di accesso è equivalente alla password, quindi se un utente malintenzionato ha messo le mani sul tuo database, potrebbe utilizzare i token per accedere a qualsiasi account, come se fossero chiari login-password combinazioni. Pertanto, utilizzare hashing forte salato (bcrypt/phpass) quando si memorizzano i token di accesso persistenti.

Sono d'accordo con la prima frase in grassetto, ma non l'ultima.

Se non mi sbaglio, lo scopo di un algoritmo di "forte hash salato" è che qualcuno non dovrebbe essere in grado di recuperare le password dato un tavolo arcobaleno.

Ma qui, la stringa con hash non è una password ma una stringa casuale . Pertanto è abbastanza improbabile che qualsiasi tabella arcobaleno sia in grado di recuperare qualsiasi stringa con hash originale. Immagino anche che potrei semplicemente usare una chiamata di base hash('sha256', $randomString) per questo, con l'obiettivo di avere valori diversi per il token nel DB e nel cookie.

Problemi correlati