Vale la pena hashing password sul lato client

Quando voglio mettere in atto un sistema di login, confronto sempre l’MD5 della password data con il suo valore nella tabella utenti sul lato server.

Tuttavia, un mio amico mi ha detto che una password “chiara” poteva essere annusata da un software di rete.

Quindi la mia domanda è: è una buona idea hash la password sul lato client? È meglio che eseguirne l’hashing sul lato server?

Fondamentalmente, il tuo amico ha ragione. Ma semplicemente l’hashing della password sul lato client è solo migliore di inviarlo come testo normale al server. Qualcuno, che può ascoltare le tue password di testo normale, è certamente in grado di ascoltare le password con hash e utilizzare questi hash catturati per autenticarsi sul tuo server.

Per questo motivo, i protocolli di autenticazione più sicuri solitamente passano attraverso una serie di canvasi per assicurarsi che un tale attacco di replay non possa funzionare, di solito, consentendo al client di selezionare un gruppo di bit casuali, che sono sottoposti a hash insieme alla password e anche inviato in chiaro al server.

Sul server:

  • generare alcuni bit di casuale
  • invia questi bit (in chiaro) al client

Sul client:

  • genera alcuni bit casuali
  • concatena la password, i bit casuali del server e i bit casuali del client
  • generare hash di quanto sopra
  • inviare dati casuali (in chiaro) e hash al server

Poiché il server conosce le proprie informazioni casuali e i bit casuali del client (li ha ottenuti come testo in chiaro), può eseguire essenzialmente la stessa trasformazione. Questo protocollo assicura che nessuno in questa conversazione possa usare le informazioni in seguito per autenticare erroneamente le informazioni registrate (a meno che non sia stato usato un algoritmo molto debole …), purché entrambe le parti generino “bit di rumore” ogni volta, viene eseguito il movimento della mano.

Modifica Tutto questo è sobject a errori e noioso e un po ‘difficile da ottenere a destra (leggi: sicuro). Se ansible, prendi in considerazione l’utilizzo di protocolli di autenticazione già scritti da persone esperte (diversamente da me!). Quanto sopra è solo a memoria di un libro che ho letto qualche tempo fa). Davvero non vuoi scriverlo di solito.

Prima di tutto, questo NON migliora la sicurezza della tua applicazione (supponendo che sia una webapp).

Usa SSL (o in realtà TLS, che viene comunemente chiamato SSL), non è molto costoso (misura il tempo che stai usando per trovare il modo per aggirarlo e moltiplicarlo con il salario minimo, acquistare un certificato vince quasi sempre).

Il perché di questo è semplice. TLS risolve un problema (se utilizzato con certificati acquistati, non autofirmati) che è abbastanza grande nella crittografia: come faccio a sapere che il server con cui sto parlando è il server con cui sto parlando? I certificati TLS sono un modo per dire: “Io, l’autorità di certificazione, fidata dal tuo browser, certifica che il sito web di [url] ha questa chiave pubblica, con una chiave privata corrispondente, che (chiave privata) conosce solo il server, guarda Ho firmato la mia firma su tutto il documento, se qualcuno lo ha modificato puoi vedere “.

Senza TLS, qualsiasi crittografia diventa inutile, perché se mi siedo accanto a te in un coffeeshop, posso fare in modo che il tuo laptop / smartphone pensi che io sia il server e MiTM (Man in the Middle). Con TLS, il tuo laptop / smartphone urlerà “CONNESSIONE NON CORRETTA”, perché non ho un certificato firmato dall’autorità di certificazione che corrisponda al tuo sito. (Crittografia contro autenticazione).

Dichiarazione di non responsabilità: gli utenti tendono a fare clic su questi avvisi: “Connessione non protetta? Cosa? Voglio solo le mie foto di gattini! Aggiungi Eccezione Fai clic su Conferma Clicca YAY! Gattini!”

Tuttavia, se davvero non vuoi comprare un certificato, continua ad implementare l’hashing javascript lato client (e usa la libreria standford (SJCL) per quello, MAI IMPLEMENTARE CRYPTO TE STESSO ).

Perché? Riutilizzo della password! Posso rubare il tuo cookie di sessione (che mi permette di fingere sul tuo server che io sia te stesso) senza HTTPS facilmente (vedi firesheep). Tuttavia se aggiungi un javascript alla tua pagina di accesso che, prima di inviarlo, blocca la tua password (usa SHA256, o meglio ancora, usa SHA256, invia loro una chiave pubblica che hai generato e poi cripta la password con hash, non puoi usare un salt con questo), quindi invia la password hash / crittografata al server. REHASH l’hash sul tuo server con un sale e confrontalo con ciò che è memorizzato nel tuo database (salva la password in questo modo:

(SHA256(SHA256(password)+salt)) 

(salva il sale anche come testo in chiaro nel database)). E invia la tua password in questo modo:

 RSA_With_Public_Key(SHA256(password)) 

e controlla la tua password in questo modo:

 if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok 

Perché, SE qualcuno sta annusando il tuo cliente, sarà in grado di accedere come tuo cliente (session hijacking) ma non vedranno MAI la password in chiaro (a meno che non alterino il tuo javascript, comunque, un hacker di Starbucks probabilmente non saprà come / sarà interessato in questo.) Così avranno accesso alla tua webapp, ma non alla loro email / facebook / etc. (per cui i tuoi utenti useranno probabilmente la stessa password). (L’indirizzo e-mail sarà il loro nome di accesso o verrà trovato nel loro profilo / impostazioni sulla tua webapp).

È probabile che tu non ti preoccupi di questo – come Dirk menziona anche se hai cancellato le password che un utente malintenzionato potrebbe trovarsi su una rete e vedere che l’hash viene inviato, e potrebbe semplicemente inviare lo stesso hash.

È leggermente migliore, in quanto impedisce all’utente malintenzionato di sapere quale sia la password, ma dal momento che può ancora accedere (o potenzialmente ribuild la password originale ), non è così utile.

In generale, se sei preoccupato per la sicurezza delle password e dei dati dell’utente (e dovresti esserlo!), Ti consigliamo di utilizzare un server SSL sicuro. Se questo non è un problema per te, per qualsiasi ragione potresti anche non preoccuparti dell’hashing; è solo sicurezza attraverso l’oscurità .


Modifica agosto 2014: Google sta spingendo sempre più fortemente affinché i siti web passino a HTTPS ovunque , poiché proteggere la comunicazione stessa è l’unico modo per prevenire gli attacchi di sniffing della rete. I tentativi di offuscare i dati trasmessi ostacoleranno, non fermeranno, un attaccante dedicato e possono dare agli sviluppatori un pericoloso falso senso di sicurezza.

In realtà non sono d’accordo che l’hashing del lato client sia più sicuro in questo caso. Penso che sia meno sicuro.

L’intero punto di memorizzazione di un hash della password nel database rispetto alla password reale (o persino una password crittografata) è che è matematicamente imansible ottenere la password originale da un hash (anche se è teoricamente ansible ottenere una collisione input hash, la cui difficoltà dipende dalla forza di sicurezza dell’algoritmo di hashing). Il ansible vettore di attacco qui è che se un potenziale aggressore compromettesse in qualche modo il database di archiviazione della password, non sarebbe comunque in grado di ottenere le password originali degli utenti.

Se il tuo meccanismo di autenticazione invia un hash della password, in questo scenario di violazione della sicurezza, l’utente malintenzionato non ha bisogno di conoscere la vera password: semplicemente invia l’hash che ha e, presto, ha accesso a un particolare account utente, e per estensione, il tuo intero sistema. In primo luogo, sconfigge completamente il punto di memorizzare una password hash!

Il modo più sicuro per farlo è di inviare al client una chiave pubblica una tantum per crittografare la password, quindi decifrare e re-hash sul lato server.

A proposito, questo tipo di domanda probabilmente otterrà risposte più esperte su Security StackExchange.

Dipende, è ansible utilizzare l’hashing del lato client, ma il server side salt non sarà ansible.

dare un’occhiata al link Crittografia password lato client

Ho lavorato molto su questo recentemente, IRL ci sono due problemi con l’hash del client / la crittografia simmetrica con l’idea di uccidere: 1. Devi recuperare il sale sul server SOMEHOW … e crittografare lato client avresti bisogno di una password … che sconfigge lo scopo. 2. Esponi la tua implementazione di hashing (non un grosso affare dato che la maggior parte dei siti usa uno o più 3 hashing algos) che rende l’attacco più semplice (basta provare uno piuttosto che n).

Alla fine ho optato per la crittografia asimmetrica sul client che utilizza OpenPGP.js o simile … Questo si basa su una chiave generata lato client o importata sul client e sul server che invia la sua chiave pubblica. Solo la chiave pubblica del cliente può essere rispedita al server. Questo protegge dagli attacchi MIM ed è sicuro quanto il dispositivo (attualmente memorizzo la chiave privata del client per impostazione predefinita in localStore, è una demo).

Il vantaggio principale di questo è che non devo mai avere i dati degli utenti memorizzati / anche in memoria non crittografati sul mio server / archivio dati (e la chiave privata del mio server è fisicamente separata)

La base di ciò era fornire alle persone un modo per comunicare in modo sicuro dove HTTPS era limitato (ad es. Iran / N. Korea atc ​​…) e anche solo un divertente esperimento.

Sono molto lontano dal primo a pensare a questo, http://www.mailvelope.com/ utilizza questo

Se qualcuno può vedere i dati dentro e fuori sulla tua connessione, allora l’autenticazione non ti salverà. Invece farei quanto segue per cose super segrete.

Password prehashed sul lato client prima di essere inviate al server. (Il server memorizza un altro valore hash e salato di quell’hash inviato dal browser).

Quindi un attacco di middle man potrebbe consentire loro di inviare lo stesso valore hash per accedere come loro, ma la password degli utenti non sarebbe nota. Ciò impedirebbe loro di provare altri servizi con le stesse credenziali per accedere altrove.

I dati degli utenti sono crittografati anche dal browser.

Ah, quindi un attacco da uomo medio otterrebbe i dati crittografati, ma non sarebbe in grado di decrittografarli senza la password effettiva utilizzata per accedere. (password utente memorizzata nel DOM sul browser al momento del login). Quindi il vero utente vedrebbe i contenuti decodificati ma l’uomo medio non potrebbe. Ciò significa anche che qualsiasi NSA o altra agenzia non sarebbe in grado di richiedere a te / azienda / fornitore di hosting di decrittografare questi dati poiché sarebbe imansible per loro farlo anche loro.

Alcuni piccoli esempi di entrambi questi metodi sono sul mio blog http://glynrob.com/javascript/client-side-hashing-and-encryption/

Recentemente sia GitHub che Twitter hanno annunciato che le password sono state memorizzate nei log interni. Ho avuto questo inavvertitamente in bug report e altri registri che hanno trovato la loro strada in splunk ecc. Per twitter se la password di Trump era lì, log potrebbe essere un grosso problema per un amministratore di “vedere”, per altri siti probabilmente non come un grosso problema dato che gli amministratori non avrebbero molto bisogno di farlo. Indipendentemente da amministratori, non ci piace vedere le password.

Quindi la domanda è davvero se l’hashing dovesse accadere lato client per sicurezza, ma come possiamo proteggere la password prima che alla fine venga sottoposta a hash e confrontata dal lato server in modo che non venga registrata in qualche modo.

La crittografia non è una ctriggers idea perché gli sviluppatori devono almeno saltare attraverso alcuni anelli e, se trovi che le password sono state inserite nei registri, puoi semplicemente cambiare la chiave di crittografia, distruggere l’originale e che i dati diventano inutili. Meglio ancora ruotare i tasti di notte e potrebbe ridurre notevolmente le windows.

Si potrebbe anche hash un hash nel record utente. Le password trapelate sarebbero password di testo semplice con hash. Il server memorizzerebbe una versione hash dell’hash. Certo l’hash diventa la password, ma a meno che tu non abbia una memoria fotografica non ricorderai un 60 char bcyrpt. Salt con il nome utente. Se si riesce a raccogliere qualcosa sull’utente durante il processo di login (pur non esponendo che il record dell’utente esiste) si può anche saltarlo creando un hash più robusto che non può essere condiviso tra i siti. Nessun uomo nel mezzo sarebbe in grado di tagliare e incollare l’hash catturato tra i siti.

Combina con un cookie che non viene inviato al server e potresti essere su qualcosa. Alla prima richiesta, invia un cookie al cliente con una chiave, quindi assicurati che il cookie non ritorni al servizio di accesso, con poche possibilità di essere registrato. Archiviare la chiave in un archivio di sessioni e quindi eliminarla subito dopo il login o quando la sessione è scaduta … questo richiede uno stato per voi ragazzi JWT, ma forse basta usare un servizio nosql per questo.

Quindi lungo la strada un amministratore trova uno di questi hash e password crittografate in splunk o uno strumento di segnalazione bug. Dovrebbe essere inutile per loro in quanto non riescono più a trovare la chiave di crittografia, e anche se lo facessero, allora avrebbero dovuto forzare un hash. Inoltre, l’utente finale non ha inviato nulla di testo in chiaro lungo la linea, quindi ogni uomo nel mezzo ha almeno un tempo più difficile e non puoi semplicemente saltare su un altro sito e accedere.

Considera questo: –

Il client invia una richiesta al server “Ho una password per convalidare”.

Il server invia al client una sola stringa casuale unica. R $

Il client incorpora la password dell’utente in questa stringa (in base a qualsiasi regola (variabile) che desideri applicare).

Il client invia la stringa al server e se la password è OK, il server registra l’utente.

Se il server riceve un’altra richiesta di accesso utilizzando R $, l’utente viene disconnesso e l’account è bloccato in attesa di indagine.

Ovviamente saranno prese tutte le altre (normali) precauzioni di sicurezza.

Si possono considerare i siti come amazon.com e linkedin.com. Questi siti non hanno hash sul lato client. (Come in aprile 2018).

Si noti che mantenere le password sicure contro parti terze non è tutto ciò che c’è da fare.

Non appena viene coinvolta la privacy (e quando mai non lo è, in questi giorni?) Non vuoi conoscere la password. Non puoi abusare o perdere ciò che non hai , così sia tu che i tuoi clienti potete dormire meglio se non vedete mai le loro password in chiaro.

Pertanto, l’hashing / crittografia lato client ha senso.

Puoi usare qualsiasi libreria di terze parti come

jCryption

Crittografia lato client con jCryption