Ci sono pochissimi siti Web che cancellano la password degli utenti prima di inviarli al server. Javascript non ha nemmeno il supporto per SHA o altri algoritmi.
Ma posso pensare ad alcuni vantaggi, come la protezione contro le perdite tra i siti o gli amministratori malintenzionati, che SSL non fornisce.
Quindi, perché questa pratica è così rara tra i siti web?
Inventore dell'hash per la password JavaScript qui
Nel 1998 stavo costruendo un Wiki, il primo sito web che avevo creato con un sistema di login. Non potevo permettermi l'hosting con SSL, ma ero preoccupato per le password in chiaro che passavano su Internet. Ho letto su CHAP (sfidare il protocollo di autenticazione hash) e ho realizzato che potevo implementarlo in JavaScript. Ho finito per pubblicare JavaScript MD5 come progetto autonomo ed è diventato l'open source più popolare che ho sviluppato. Il wiki non è mai andato oltre alpha.
Rispetto al protocollo SSL ha una serie di punti deboli:
Ho sempre affermato queste limitazioni in anticipo. Sono stato periodicamente fiammeggiato per loro. Ma mantengo il principio originale fino ad oggi: se non hai SSL per qualsiasi motivo, questo è meglio delle password in chiaro. Nei primi anni 2000 un certo numero di grandi fornitori (in particolare Yahoo!) lo usavano per gli accessi. Ritenevano che SSL anche solo per gli accessi avrebbe avuto troppi costi aggiuntivi. Penso che siano passati a SSL solo per gli accessi nel 2006, e intorno al 2011 quando è stato rilasciato Firesheep, la maggior parte dei provider è passato a SSL completo.
Quindi la risposta breve è: L'hashing sul lato client è raro perché le persone usano SSL invece.
Ci sono ancora alcuni potenziali benefici dell'hash sul lato client:
In definitiva, anche se questi benefici sono minori e aggiungono molta complessità, c'è il rischio reale che introduca una vulnerabilità più seria nel tentativo di migliorare la sicurezza. E per le persone che vogliono più sicurezza della password, l'autenticazione a più fattori è una soluzione migliore.
Quindi la seconda risposta breve è: perché l'autenticazione a più fattori offre maggiore sicurezza rispetto all'hash della password sul lato client.
Per comprendere questo problema, devi prima capire perché abbiamo le password hash. È completamente possibile memorizzare una password in chiaro su un server e confrontare semplicemente la password trasmessa alla password ricevuta. Finché la password è protetta durante il transito, questo è un mezzo di autenticazione sicuro (segreto condiviso).
Il motivo per cui le password sono hash è perché il problema non è l'autenticazione, ma l'archiviazione. Se il server viene mai compromesso, l'utente malintenzionato ha immediatamente accesso a tutti gli account utente poiché ora conoscono il segreto utilizzato per l'autenticazione degli utenti.
L'hashing funge da barriera a questo. Poiché il server non conosce l'effettivo input richiesto per l'autenticazione, anche un compromesso al DB non garantisce a un utente malintenzionato l'accesso agli account utente. Avrebbero ancora bisogno di capire l'input da dare per raggiungere i valori hash a cui l'applicazione fa riferimento. Certo, potrebbero modificare tutti i valori in qualcosa che sanno, ma questo potrebbe sollevare rapidamente sospetti e il sistema dovrebbe essere chiuso e protetto.
Quindi, il problema con l'hashing del lato client è che rende effettivamente il risultato dell'hash la password piuttosto che la password. Non c'è nulla che impedisca a un utente malintenzionato di aggirare il client ufficiale e semplicemente di inviare direttamente l'hash finito al server. Non fornisce alcuna ulteriore (o perdita) di sicurezza durante l'autenticazione, ma nella situazione in cui l'hashing è progettato per la protezione, non offre nulla poiché l'hash memorizzato nel DB è in realtà il segreto condiviso trasmesso al server.
Detto questo, ci sono due cose notevoli che l'hashing lato client ti dà. Anche se non aiuta a proteggere il tuo sistema, può aiutare a proteggere il tuo utente. Se si trasmette la password in modo non sicuro o la trasmissione viene compromessa senza che il codice client venga compromesso, si continuerà a proteggere la password dell'utente (che potrebbero essere riutilizzati su altri siti) da eventuali perdite.
L'altro è che è possibile fornire iterazioni aggiuntive di un hash per rendere più difficile un attacco offline contro il DB senza dover utilizzare cicli del server (mentre si estende anche la lunghezza della "password intermedia che il client invia"), ma hai ancora bisogno di cicli di server sufficienti per proteggere la password estesa contro un client canaglia. Anche in questo caso, la protezione primaria che offre impedisce la scoperta della password originale, ma non aiuta a proteggere il meccanismo di autenticazione del tuo sito.
In altre parole, mentre fornisce alcune protezioni minori, dal punto di vista del server, l'hash del lato client dovrebbe essere trattato come se fosse la password diretta dell'utente. Non fornisce né più né meno sicurezza sul server se l'utente avesse fornito direttamente la propria password e dovesse essere protetto come tale.
Se vuoi essere in grado di fornire quel livello extra di sicurezza, consiglierei due hash. Hash una volta lato client per creare una nuova password univoca, quindi eseguire l'hashing della password sul server per creare un valore memorizzato nel DB. In questo modo ottieni il meglio da entrambi i mondi.
Per la maggior parte, SSL è sufficientemente affidabile per proteggere lo scambio che l'hash iniziale prima della trasmissione è visto come non necessario e un server compromesso potrebbe sempre alterare il codice inviato al client in modo tale che l'hash iniziale non venga eseguito . Semplicemente non è un'alternativa efficace a SSL e non offre un vantaggio aggiuntivo sufficiente a valerne i costi e la complessità.
Se hai un bel po 'di vantaggi, dovresti elencarli nella tua domanda in modo che le persone possano scoprire se sono veramente utili (e potresti diventare famoso in tal caso;)
Le persone non preferiscono l'hashing sul lato client perché hanno modi migliori di proteggere le informazioni private degli utenti. Pensiamo ai luoghi con potenziali perdite di informazioni e ce ne sono tre:
Quindi vediamo perché o perché no hashing sul lato client sarà di aiuto in questi luoghi.
Il client.
Se ci sono malware sul tuo computer, per esempio, se il tuo browser è compromesso o il tuo computer è impiantato con software di key-logging, l'hashing sul lato client non impedisce a un hacker di ottenere la tua password. La ragione è ovvia.
Tra il client e il server.
C'è il canale di comunicazione tra client e server. Se c'è un intercettatore che ascolta la comunicazione, l'hashing sul lato client può rendere più difficoltosa la perdita della password, perché l'intercettatore deve recuperare la password originale dal suo hash. È davvero utile qui.
Tuttavia, questa vulnerabilità si basa sul presupposto di un canale di comunicazione non sicuro. In realtà, ci sono protocolli la cui esistenza cerca di risolvere esattamente questo problema. Il loro compito principale è stabilire un canale sicuro su uno insicuro. L'esempio più famoso e ampiamente distribuito è SSL / TLS e offre più funzionalità e una maggiore sicurezza rispetto all'hashing sul lato client.
La conclusione è che l'hashing sul lato client è utile nel canale, ma qui ci sono strumenti migliori.
Il server.
Le informazioni degli utenti potrebbero essere trapelate sul server se il server viene compromesso da un hacker. L'hacker può recuperare le password degli utenti dal database se sono archiviate in testo normale. Ecco perché oggi la maggior parte dei server non lo fa. Al contrario, memorizzano hash di password in modo che gli hacker non possano facilmente ripristinare le password originali dalle loro informazioni a disposizione (ad esempio hash).
Potresti essere tentato di credere che le cose funzionino ancora bene se il server memorizza semplicemente gli hash calcolati sul lato client. Ma questo è gravemente sbagliato. In quella situazione gli stessi hash diventano password equivalenti. L'hacker può passare l'autenticazione semplicemente passando l'hash senza invertirlo. L'obiettivo di un hacker non è l'annullamento di un hash, ma l'apertura del tuo account. L'importanza risiede nel processo di verifica del server sui dati del cliente, non sul fatto che i dati siano un valore hash. Pertanto il vantaggio dell'hash lato client è banale e il server deve comunque eseguire nuovamente il rehash.
Per riassumere, l'hashing sul lato client è utile per proteggere le informazioni dell'utente, ma la protezione si applica in gran parte al canale di comunicazione. Dal momento che abbiamo approcci migliori (SSL / TLS), l'applicazione dell'hash sul lato client è notevolmente surpressa. Semplicemente non è lo strumento migliore per l'attività in corso.
Quali vantaggi avrebbe l'hashing della password lato client?
Bene, la password non verrebbe inviata in rete in chiaro. Ma dovresti davvero usare la crittografia TLS quando effettui il login, quindi l'annidamento della password non dovrebbe essere un problema.
Un altro motivo potrebbe essere che non si desidera che il server mai sia a conoscenza della password dell'utente, nemmeno per un microsecondo. Ciò significa che fornisci al server l'hash della password durante la registrazione e quindi accedi utilizzando l'hash della password. Purtroppo questo non risolve nulla: il segreto condiviso per accedere all'account è ora l'hash, non la password. Quando si ottiene la conoscenza dell'hash, è possibile accedere senza conoscere la password effettiva (perché anche il server non lo sa).
È buona pratica eseguire l'hash sul lato client, quindi eseguire nuovamente la password e l'hash sul lato server. Questo è un ulteriore livello di protezione contro l'uomo negli attacchi centrali. SSL è il primo livello, ma le rivelazioni di Snowden hanno chiarito che SSL può essere compromesso da organizzazioni come la NSA con relativa facilità.
Dato che stai parlando dell'applicazione web ...
In un database abbiamo una chiamata alla tabella dbo.useracc che stiamo memorizzando la password di hash
User Password
-------- ----------
user1 5f4dcc3b5aa765d61d8327deb882cf99
user2 202cb962ac59075b964b07152d234b70
user3 098f6bcd4621d373cade4e832627b4f6
e la nostra funzione di login nell'applicazione web è qualcosa come
if (user == $user and password == $pass) {
return auth.token
}
Supponiamo che un utente malintenzionato abbia hackerato e rubato il database e salvato i nostri dati dbo.useracc. Ora ha la nostra password con hash.
Se il processo di hash di login è archiviato nel client, l'utente malintenzionato può comunque accedere al tuo account con la password con hash semplicemente collegando il metodo HTTP POST modificando il campo della password per inviare la tua password hash ed è ancora in grado di accedere. Ricorda che i dati dell'applicazione comunicano con il server tramite il metodo POST, eventualmente dopo che è stato verificato l'hash.
Tuttavia, se il processo di hashing è nel server, è un'altra storia.
$pass = md5.hash($pass);
if (user == $user and password == $pass) {
return auth.token;
}
Se l'hacker utilizza la password con hash per accedere, sarà una hash "hashed password" che verifica su una password con hash.
In questo caso, diciamo il post dell'attaccante
$ utente = utente1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99
Dopo che il server ha eseguito $ pass = md5.hash (5f4dcc3b5aa765d61d8327deb882cf99) restituirà '696d29e0940a4957748fe3fc9efd22a3' che restituisce una falsa dichiarazione.
Serve a bloccare l'aggressore che ha rubato con successo i dati del database e sta tentando di accedere attraverso l'applicazione web utilizzando la password con hash. E naturalmente l'attaccante può ancora hackerare gli account se riescono a forzare bruteforce / crack degli hash attraverso gli attacchi del dizionario e così via. Tuttavia, l'hacker richiede più tempo se la password è una buona password dopo aver compromesso il sistema e l'amministratore del server potrebbe semplicemente reimpostare la password e inviare email agli utenti.
Inoltre è anche usato per minacce interne come i dipendenti di un'azienda. In un'azienda, ci sarà un amministratore di database e sviluppatori. Sono ruoli diversi. Ora per impedire agli utenti dei dipendenti di accedere ai dati sensibili, devono avere accesso sia all'applicazione che al DB per ottenere l'accesso ai dati. Ovviamente si potrebbe obiettare che un DBA può ancora alterare i dati del database attraverso il database stesso, ma non è accessibile agli sviluppatori ed è più facile individuare da dove viene l'attacco. Riguarda i diritti di controllo degli accessi e riduce al minimo i rischi e le minacce.
Anche se l'argomento ha dei punti di perdita concreti, come sottolineato da @Cyker, la discussione è un po 'vivace qui ... Mi piacerebbe aggiungere un punto che non ho visto menzionato.
È semplicemente che se si esegue l'hashing ASAP, si riducono i rischi di programmazione di passare accidentalmente una password di testo chiaro da qualche parte che non dovrebbe andare. Prendiamo già misure come stringhe sicure e array sicuri per cercare di distruggere il testo chiaro al più presto; e l'hashing nel momento in cui ottieni la password è un'altra misura del genere ... Mentre il codice si evolve, ecc., i rischi sembrano essere ancora ridotti.
Ho appena scritto un piccolo C # "Box" che prende il testo chiaro di SecureString e lo blocca immediatamente --- in questo modo so semplicemente che non verrà mai registrato o passato a una libreria che non mi aspetto. Non si tratta tanto di un protocollo in quanto è solo il programmatore qui seduto a guardare una password --- non voglio toccarlo! (È ancora una parola d'ordine equivalente in alcuni aspetti, ma è almeno immediatamente nascosta alla follia come spostare una parentesi chiusa in una chiamata a metodo concatenata e passare il testo chiaro nel posto sbagliato e una matrice sicura non è ancora nascosta.)
Sono d'accordo che se SSL / TLS è disponibile, il vantaggio dell'hashing lato client per proteggere il processo di autenticazione è limitato. Tuttavia, SSL / TLS non risolve la vulnerabilità agli attacchi hardware personalizzati se l'utente malintenzionato ha accesso agli hash memorizzati (DOPO il processo). Funzioni come hash salati semplici o schemi come PBKDF2 sono molto vulnerabili a questi attacchi a causa dei loro bassi requisiti di memoria. Il cracking delle password, protetto con questi schemi è economico e veloce. E questo è almeno uno dei principali problemi di hashing della password.
A prima vista, questo non ha nulla a che fare con l'hashing lato client rispetto a SSL / TLS - ma: Quando un server implementa uno schema di hashing delle password hard-memory come Scrypt, Argon2 o Catena per proteggere gli attacchi hardware personalizzati, i requisiti hardware del server aumentano drasticamente. In realtà, i servizi riducono quindi la durezza della memoria o passano a schemi vulnerabili. L'hashing sul lato client aiuta un po 'a risolvere questo problema. Quando i client calcolano queste costose funzioni (hard di memoria), il servizio può utilizzarle senza la necessità di un hardware migliore.
I moderni schemi di hashing delle password offrono quindi la possibilità di delegare al client le parti più costose (più difficili da utilizzare) della funzione. Questa funzione è chiamata relief server ed è offerta da Argon2 e Catena.
Conclusione: l'uso di moderni schemi di hashing delle password, che sono molto meno vulnerabili agli attacchi hardware personalizzati, aumenterà o almeno dovrebbe aumentare l'uso dell'hash del lato client in futuro, naturalmente insieme a SSL / TLS.
Salterò qui con l'esplicito proposito di ponderare il meccanismo di hashing sul lato client. Vediamo come questo ci avvantaggia:
lato client: Nessun miglioramento.
In transito: Protegge la password in caso di SSLstrip in cui la password finisce per essere trasmessa in chiaro. Tuttavia, se HSTS è implementato, la maggior parte delle persone direbbe che SSLStrip non avrebbe alcun effetto. Destra? No.
Alla voce sul server: Infine, vediamo il principale vantaggio. Cosa succede se qualcuno ha compromesso il server? Ricevono un flusso continuo di password in chiaro se avviano semplicemente Wireshark / TCPDump ed esportano la chiave privata del server. Ora possono restare sul filo per un paio di mesi, e per i server ad alto volume (milioni di registrazioni utente al mese), ottengono la loro massiccia violazione del testo normale. Ciò presuppone che sia più utile afferrare le password per gli utenti del servizio piuttosto che avere RCE sul loro server, naturalmente.
Sul server: Prestazioni in termini di prestazioni se non è necessario eseguire bcrypt su ogni password in ingresso, che consente di scaricare alcuni costi di calcolo sul client senza introdurre nuove vulnerabilità. Questo sembra essere un aspetto positivo per l'amministratore del tuo server, oltre ai costi dell'hardware.
Tuttavia, sembra una buona prassi incorporare l'hashing della password sul lato client a meno che non crei tempi di caricamento delle pagine insopportabili per gli utenti.
Penso che l'hash lato client abbia un lato positivo e uno svantaggio:
pro: si nasconde la password in caso di dns / phishing / qualunque, che è utile per l'utente, dal momento che molte persone riutilizzano le password su diversi servizi. Come altri sviluppatori hanno detto, questo non fa nulla per la tua sicurezza.
cons: il tuo server non ottiene la password, il che impedisce a cose come avvertire l'utente della forza della password. So che alcuni diranno che questo può / dovrebbe essere lato client, ma quando si hanno più client, può essere bello centralizzare il lato server.
Penso che la probabilità di essere hackerata sul lato client sia più alta di quella sul lato server. (Perché ci sono alcuni esperti IT che si occupano del server). se il tuo computer è già stato violato anche gli algoritmi del lato client utilizzati per l'hashing della tua password possono essere rubati dall'hacker. Anche se i tuoi algoritmi non sono più un segreto. Penso che diventi inutile.
Leggi altre domande sui tag authentication passwords hash account-security password-cracking