credenziali di hashing. Hash (email + password) è abbastanza sicuro?

Obbligatorio: non lanciare la tua crittografia ....

In base ai tuoi commenti, non stai chiedendo alcun algoritmo specifico, ma se la modifica dell'hash input da password a email+password fornisce una sicurezza aggiuntiva.

Email inviata: [email protected] con password My @wesome pa$$w0rd FTW YO!!!!

• Quindi il tuo input nell'algoritmo hash ora è più lungo e meno probabile che sia in una tabella arcobaleno e richiederà più tempo per ottenere il testo in chiaro
• Come hai notato in un commento, potresti utilizzare l'email come un valore salt, ma probabilmente meglio usare un valore casuale e qui
• A seconda di alcuni dettagli di implementazione, l'indirizzo email potrebbe ancora essere esposto; se non hai bisogno dell'indirizzo email e non utilizzerai mai il valore altrove, perché richiedere un indirizzo email invece di un solo nome utente. Potresti anche incorrere in problemi con la reimpostazione della password o la gestione degli utenti.

Make the server client authentication more efficient.

Perché è più efficiente? Un'implementazione Javascript nel browser potrebbe essere piuttosto lenta e potrebbe essere soggetta a compromessi poiché si ha lo stesso livello di sicurezza nel browser dell'utente (non sotto il proprio controllo) come sul proprio server. Vuoi che il tuo hashing sia lento in generale, non veloce quando si tratta di password.

Inoltre, per quest'ultima parte:

Store the same hash on server and on client (only calculate the hash once on each side)

Sembra che tu voglia ridurre il carico del server calcolando l'hash sul client e inviandolo al server? Quindi nel tuo DB cerchi quel valore con il valore nel database? Ciò potrebbe non fare ciò che si pensa a seconda dell'implementazione, ad esempio l'invio dell'hash sulla rete per essere confrontato con il valore nel DB; se il DB è compromesso, l'attaccante ha il valore di input, quindi è come fare un testo in chiaro. Si desidera impedire a qualcuno che ottiene il DB di poter accedere tramite il canale legit. Controlla " Sfida impegnativa: client- hashing della password lato e verifica della password sul lato server "

L'implementazione in cui si utilizza l'e-mail come sale non è buona. Un sale è preferibilmente generato in modo casuale da crittografia. Ciò garantisce che il sale sia globalmente unico. Ciò significa che se una persona usa la stessa password su due diverse applicazioni, entrambe le password avranno un aspetto diverso. Con il tuo schema in cui usi l'indirizzo email come salt, la password con hash tra due applicazioni sarà la stessa.

Inoltre penso che dovresti leggere l'hashing delle password e quali sono gli algoritmi accettabili. Attualmente puoi usare:

• scrypt
• bcrypt
• pbkdf2

Ciascuno di questi è buono e la maggior parte delle librerie genererà il sale correttamente per te.

Per favore non usare un hash md5 / sha / smth per memorizzare password, salate o altro. Gli hash generici sono progettati per essere veloci - posso md5 un file 9Gb sul mio laptop in 20 secondi. Non vuoi che i tuoi hash della password siano veloci da calcolare.

Usa qualcosa che in realtà è pensato per password di hash sicure - Gli esperti di sicurezza consigliano bcrypt per l'archiviazione delle password?

Se il tuo unico scopo è quello di rendere le cose rapide e semplici, potresti anche memorizzare la password come testo in chiaro; sha1(email + password) può essere rotto molto rapidamente sull'hardware di oggi che non vale quasi il "problema".