it-swarm-eu.dev

Perché l'hash sul lato client di una password è così raro?

Esistono pochissimi siti Web che eseguono l'hashing della password dell'utente prima di inviarla al server. Javascript non ha nemmeno il supporto per SHA o altri algoritmi.

Ma riesco a pensare ad alcuni vantaggi, come la protezione da perdite tra siti o amministratori malevoli, che SSL non fornisce.

Allora perché questa pratica è così rara tra i siti Web?

86
Muis

Inventore dell'hash delle password JavaScript qui

Nel lontano 1998 stavo costruendo un Wiki, il primo sito Web che avevo realizzato con un sistema di login. Non potevo permettermi l'hosting con SSL, ma ero preoccupato per le password in chiaro che passavano su Internet. Avevo letto di CHAP (challenge hash Authentication Protocol) e mi ero reso conto che avrei potuto 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 l'alfa.

Rispetto a SSL presenta una serie di punti deboli:

  • Protegge solo dalle intercettazioni passive. Un MITM attivo può manomettere JavaScript e disabilitare l'hash.
  • Gli hash sul lato server diventano equivalenti con password. Almeno nell'attuazione comune; ci sono variazioni che evitano questo.
  • Gli hash catturati possono essere forzati brutalmente. È teoricamente possibile evitarlo usando JavaScript RSA.

Ho sempre dichiarato queste limitazioni in anticipo. Ero periodicamente infiammato per loro. Ma mantengo il principio originale fino ad oggi: se non hai SSL per qualsiasi motivo, è meglio delle password in chiaro. All'inizio degli anni 2000 un certo numero di grandi fornitori (in particolare Yahoo!) lo utilizzavano per gli accessi. Credevano che SSL anche solo per gli accessi avrebbe avuto un sovraccarico eccessivo. Penso che siano passati a SSL solo per gli accessi nel 2006 e verso il 2011, quando è stato rilasciato Firesheep, la maggior parte dei provider è passata a SSL completo.

Quindi la risposta breve è: l'hash sul lato client è raro perché le persone usano invece SSL.

Ci sono ancora alcuni potenziali vantaggi dell'hashing lato client:

  • Alcuni software non sanno se verrà distribuito con SSL o meno, quindi ha senso includere l'hash. vBulletin ne era un esempio comune.
  • Rilievo del server - con hash computazionalmente costosi, ha senso per il client svolgere una parte del lavoro. Vedi questa domanda .
  • Amministratori dannosi o server compromessi: l'hash sul lato client può impedire loro di vedere password in chiaro. Questo di solito viene respinto perché potrebbero modificare JavaScript e disabilitare l'hash. Ma in tutta onestà, quell'azione aumenta le loro possibilità di essere rilevata, quindi c'è qualche merito in questo.

Alla fine, sebbene questi vantaggi siano minori e aggiungano molta complessità, c'è un rischio reale che tu introduca una vulnerabilità più grave nel tuo tentativo di migliorare la sicurezza. E per le persone che desiderano più sicurezza della password, l'autenticazione a più fattori è una soluzione migliore.

Quindi la seconda risposta breve è: perché l'autenticazione a più fattori fornisce più sicurezza dell'hash delle password sul lato client.

52
paj28

Per capire questo problema, prima devi capire perché abbiamo le password di hash. È completamente possibile memorizzare una password in testo normale su un server e confrontare semplicemente la password trasmessa con la password ricevuta. Finché la password è protetta durante il trasporto, si tratta di un mezzo di autenticazione sicuro (segreto condiviso).

Il motivo per cui le password sono sottoposte a hash è perché il problema non è l'autenticazione, ma l'archiviazione. Se il server viene mai compromesso, l'utente malintenzionato avrebbe 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'input effettivo richiesto per l'autenticazione, anche un compromesso per il DB non garantisce a un utente malintenzionato l'accesso agli account utente. Avrebbero comunque bisogno di capire l'input da fornire per raggiungere i valori di hash contro cui l'applicazione verifica. Sicuramente potrebbero alterare tutti i valori in qualcosa che conoscono, ma ciò desterebbe rapidamente sospetti e il sistema sarebbe chiuso e protetto.

Quindi, il problema con l'hash del lato client è che rende efficace il risultato dell'hash la password anziché la password. Non c'è nulla che impedisca a un utente malintenzionato di ignorare il client ufficiale e di inviare semplicemente l'hash finito al server direttamente. Non fornisce ulteriore (o perdita) di sicurezza durante l'autenticazione, ma nella situazione in cui l'hashing è progettato per proteggere, non offre nulla in quanto l'hash memorizzato nel DB è in realtà il segreto condiviso trasmesso al server.

Detto questo, ci sono due cose notevoli che l'hashish lato client ti dà. Anche se non aiuta affatto a proteggere il tuo sistema, può aiutare a proteggere il tuo utente. Se si sta trasmettendo in modo non sicuro la password o la trasmissione viene compromessa senza che il codice client venga compromesso, si proteggerà comunque la password dell'utente (che potrebbe riutilizzare su altri siti) da eventuali perdite.

L'altro è che puoi fornire iterazioni aggiuntive di un hash per rendere più difficile un attacco offline contro il DB senza dover usare i cicli del server (estendendo anche la lunghezza della "password intermedia che il client invia"), ma hai ancora bisogno cicli server sufficienti per proteggere la password allungata da un client non autorizzato. Ancora una volta, la protezione primaria che offre impedisce la scoperta della password originale, ma non fa nulla per aiutare a proteggere il meccanismo di autenticazione del tuo sito.

Detto in altro modo, sebbene offra alcune protezioni minori, dal punto di vista del server, l'hash lato client dovrebbe essere trattato come se fosse la password diretta dell'utente. Fornisce una sicurezza maggiore o minore sul server rispetto a se l'utente avesse fornito direttamente la propria password e dovrebbe essere protetto come tale.

Se vuoi essere in grado di fornire quel livello extra di sicurezza, consiglierei due hash. Hash una volta sul lato client per creare una nuova password univoca, quindi hash quella 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 è considerato non necessario e un server compromesso può sempre modificare 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 abbastanza vantaggio aggiuntivo per valere costi e complessità.

47
AJ Henderson

Se hai molti vantaggi, dovresti elencarli nella tua domanda in modo che le persone scoprano se sono veramente utili (e potresti diventare famoso in tal caso;)

Le persone non preferiscono l'hash 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:

  • Il cliente.
  • Tra il client e il server.
  • Il server.

Vediamo quindi perché o perché l'hashing lato client non sarà di aiuto in questi luoghi.

  • Il cliente.

    Se ci sono malware sul tuo computer, ad esempio, se il tuo browser è compromesso o il tuo computer è impiantato con un software di registrazione delle chiavi, l'hash sul lato client non impedisce a un hacker di ottenere la tua password. Il motivo è ovvio.

  • Tra il client e il server.

    C'è il canale di comunicazione tra client e server. Se c'è un intercettatore che ascolta la comunicazione, allora l'hash sul lato client può rendere più difficile la perdita della password perché l'intercettazione deve recuperare la password originale dal suo hash. È davvero utile qui.

    Tuttavia, questa vulnerabilità si basa sul presupposto di un canale di comunicazione insicuro. In realtà, ci sono protocolli la cui esistenza cerca di risolvere esattamente questo problema. Il loro compito principale è quello di stabilire un canale sicuro su uno insicuro. L'esempio più famoso e ampiamente diffuso è SSL/TLS e offre più funzionalità e una migliore sicurezza rispetto all'hash sul lato client.

    La conclusione è che l'hash sul lato client è utile nel canale, ma qui ci sono strumenti migliori.

  • Il server.

    Le informazioni degli utenti potrebbero essere divulgate sul server se il server è 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 gli hash delle password in modo che gli hacker non possano facilmente ripristinare le password originali dalle loro informazioni a portata di mano (cioè gli 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 hash stessi diventano equivalenti password. L'hacker può passare l'autenticazione semplicemente consegnando l'hash senza invertirlo. L'obiettivo di un hacker non è invertire un hash, ma entrare nel tuo account. L'importanza sta nel processo di verifica del server sui dati client, non sul fatto che i dati siano un valore hash. Pertanto il vantaggio di lato client hashing è insignificante qui e il server deve comunque eseguire il rehash.

Riassumendo, l'hash sul lato client è utile per proteggere le informazioni dell'utente, ma la protezione si applica in gran parte al canale di comunicazione. Poiché abbiamo approcci migliori lì (SSL/TLS), l'applicazione dell'hash sul lato client è molto sorpresa. Non è semplicemente lo strumento migliore per l'attività da svolgere.

22
Cyker

Quali vantaggi avrebbe l'hashing delle password sul lato client?

Bene, la password non verrebbe inviata via rete in chiaro. Ma dovresti davvero utilizzare la crittografia TLS quando accedi, quindi lo sniffing 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 si fornisce al server l'hash della password al momento della registrazione e quindi si accede utilizzando tale 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 (poiché neanche il server la conosce).

6
Philipp

È buona norma eseguire l'hash sul lato client, quindi salare la password e eseguire nuovamente l'hash sul lato server. Questo è un ulteriore livello di protezione contro l'uomo in mezzo agli attacchi. SSL è il primo livello, tuttavia le rivelazioni di Snowden hanno chiarito che SSL può essere compromesso da organizzazioni come NSA con relativa facilità.

6
Mayhem Software

Dal momento che stai parlando di un'applicazione web ...

In un database abbiamo una tabella chiamata dbo.useracc che stiamo memorizzando questi hash password

User        Password
--------       ----------
user1       5f4dcc3b5aa765d61d8327deb882cf99
user2       202cb962ac59075b964b07152d234b70
user3       098f6bcd4621d373cade4e832627b4f6

e la nostra funzione di accesso nell'applicazione web potrebbe essere qualcosa di simile

if (user == $user and password == $pass) {
           return auth.token
}

Supponiamo che un utente malintenzionato abbia hackerato e rubato con successo il database e salvato i nostri dati dbo.useracc. Ora ha la nostra password con hash.

Se il processo di hash di accesso è archiviato nel client, l'utente malintenzionato può comunque accedere al tuo account con la password con hash agganciando semplicemente il metodo HTTP POST che modifica il campo password per inviare la password con hash e lui è ancora in grado di accedere. Ricorda che i dati della tua applicazione comunicano con il server tramite il metodo POST alla fine dopo che è stato verificato il controllo 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 "password con hash" che controlla una password con hash.

In questo caso, diciamo il post dell'attaccante

$ user = user1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99

Dopo che il lato server sta eseguendo $ pass = md5.hash (5f4dcc3b5aa765d61d8327deb882cf99) restituirà '696d29e0940a4957748fe3fc9efd22a3' che restituisce una dichiarazione falsa.

Questo per bloccare l'attaccante che ha rubato con successo i dati del database e ha tentato di accedere attraverso l'applicazione Web utilizzando la password con hash. E, naturalmente, l'attaccante può ancora hackerare gli account se riesce a forzare/rompere gli hash con successo 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 tramite e-mail agli utenti.

Inoltre, viene utilizzato anche per minacce interne come i dipendenti di un'azienda. In un'azienda ci saranno amministratori e sviluppatori di database. Sono ruoli diversi. Ora per impedire agli utenti dipendenti di accedere ai dati sensibili, devono avere accesso sia all'applicazione che al DB per ottenere l'accesso ai dati. Naturalmente si potrebbe sostenere che un DBA può ancora modificare i dati del database attraverso il database stesso, ma non è accessibile dagli sviluppatori ed è più facile individuare da dove provenga l'attacco. Riguarda i diritti di controllo dell'accesso e minimizza i rischi e le minacce.

3
Sky

Sebbene l'argomento abbia alcuni punti di perdita concreti, come sottolineato da @Cyker, la discussione è un po 'vivace qui ... Vorrei aggiungere un punto che non ho visto menzionato.

È semplicemente che se si esegue l'ASH al più presto, si riducono i rischi di programmazione del passaggio accidentale di una password in chiaro da qualche parte che non dovrebbe andare. Adottiamo già misure come stringhe sicure e array sicuri per cercare di distruggere il testo in chiaro AL PIÙ PRESTO; e l'hashing nel momento in cui ottieni la password è un'altra misura del genere ... Man mano che il codice si evolve, ecc. i rischi sembrano essere ancora ridotti.

Ho appena scritto un piccolo "box" C # che prende il testo in chiaro di SecureString e lo mette immediatamente in hash --- 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 e guardando una password --- Non voglio toccarlo! (È ancora una password equivalente in alcuni aspetti, ma è almeno immediatamente nascosta dalla follia come spostare una parentesi chiusa in una chiamata a metodo incatenato e passare un testo chiaro nel posto sbagliato. E un array sicuro non è ancora nascosto.)

3
Steven Coco

Ho intenzione di saltare qui con lo scopo esplicito di ponderare a favore del meccanismo di hashing 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 viene implementato HSTS, la maggior parte delle persone direbbe che SSLStrip non avrebbe alcun effetto. Giusto? n.

All'ingresso al server: finalmente vediamo il vantaggio principale. Cosa succede se qualcuno ha compromesso il server? Ottengono un flusso continuo di password in chiaro se avviano semplicemente Wireshark/TCPDump ed esportano la chiave privata del server. Ora possono sedersi sul filo per un paio di mesi e per server ad alto volume (milioni di registrazioni utenti al mese) ottengono la loro massiccia violazione del testo in chiaro. Ciò presuppone che sia più importante acquisire le password per le persone nel servizio che avere RCE sul loro server, ovviamente.

Sul server: vantaggi in termini di prestazioni se non è necessario eseguire bcrypt su tutte le password in entrata, il che comporta lo scaricamento di alcuni costi di calcolo sul client senza introdurre nuove vulnerabilità. Questa sembra essere una buona cosa per l'amministratore del tuo server così come i costi dell'hardware.

Tuttavia, sembra che la migliore pratica sarebbe quella di incorporare l'hash della password nel lato client a meno che non crei tempi di caricamento della pagina insopportabili per gli utenti.

1
DeepS1X

Sono d'accordo che se SSL/TLS è disponibile il vantaggio dell'hash sul lato client per proteggere il processo di autenticazione è limitato. Tuttavia, SSL/TLS non risolve la vulnerabilità agli attacchi hardware personalizzati se l'attaccante ha accesso agli hash archiviati (DOPO il processo). Funzioni come semplici hash salati o schemi come PBKDF2 sono molto vulnerabili a questi attacchi a causa dei loro bassi requisiti di memoria. Il crack delle password, protetto con questi schemi, è economico e veloce. E questo è almeno uno dei principali problemi di hashing delle password.

A prima vista, questo non ha nulla a che fare con l'hash sul lato client rispetto a SSL/TLS, ma: quando un server implementa uno schema di hashing della password difficile da memoria come Scrypt, Argon2 o Catena per proteggere gli attacchi hardware personalizzati, l'hardware del server i requisiti aumentano notevolmente. In realtà, i servizi riducono quindi la durezza della memoria o passano a schemi vulnerabili. L'hash sul lato client aiuta un po 'a risolvere questo problema. Quando i client calcolano queste costose funzioni (memoria dura), il servizio può usarle 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 (difficili da memoria) della funzione. Questa funzione si chiama server relief ed è offerta da Argon2 e Catena.

Conclusione: l'utilizzo dei moderni schemi di hashing delle password, che sono molto meno vulnerabili agli attacchi hardware personalizzati, aumenterà o almeno dovrebbe aumentare l'uso dell'hash lato client in futuro, ovviamente insieme a SSL/TLS.

1
BeloumiX