Inventore dell'hashing delle password JavaScript qui

Nel lontano 1998 stavo costruendo un Wiki, il primo sito web che avevo costruito con un sistema di login. Non potevo permettermi l'hosting con SSL, ma ero preoccupato per le password in chiaro su Internet. Ho letto di CHAP (challenge hash authentication protocol) e ho capito 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 l'alfa.

Rispetto a SSL ha una serie di punti deboli:

• Protegge solo dalle intercettazioni passive. Un MITM attivo può manomettere JavaScript e disabilitare l'hashing.
• Gli hash lato server diventano equivalenti di password. Almeno nell'attuazione comune; ci sono variazioni che lo evitano.
• Gli hash catturati possono essere forzati. In teoria è possibile evitarlo utilizzando JavaScript RSA.

Ho sempre affermato queste limitazioni in anticipo. Ero abituato a ricevere periodicamente delle fiamme per loro. Ma mantengo il principio originale fino ad oggi: se non hai SSL per qualsiasi motivo, questo è meglio delle password in chiaro. All'inizio degli anni 2000 un certo numero di grandi provider (in particolare Yahoo!) lo utilizzavano per i login. 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 intorno al 2011, quando è stato rilasciato Firesheep, la maggior parte dei provider è passata a SSL completo.

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

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

• Alcuni software non sanno se verranno distribuiti con SSL o no, quindi ha senso includere l'hashing. vBulletin era un esempio comune di questo.
• Sollievo per il server: con hash costosi dal punto di vista computazionale, ha senso che il client svolga parte del lavoro. Vedi questa domanda.
• Amministratori dannosi o server compromesso: l'hashing lato client può impedire loro di vedere le password in chiaro. Questo di solito viene ignorato perché potrebbero modificare JavaScript e disabilitare l'hashing. Ma in tutta onestà, quell'azione aumenta le loro possibilità di essere rilevati, quindi c'è qualche merito in questo.

In definitiva, anche se questi vantaggi sono minori e aggiungono molta complessità, c'è un rischio reale che introdurrai una vulnerabilità più grave nel tuo tentativo di migliorare la sicurezza. E per le persone che desiderano una maggiore sicurezza rispetto alla password, l'autenticazione a più fattori è una soluzione migliore.

Quindi la seconda risposta breve è: perché l'autenticazione a più fattori fornisce più sicurezza rispetto all'hashing della password lato client .

Per comprendere questo problema, devi prima capire perché abbiamo hash delle password. È 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 transito, questo è un mezzo di autenticazione sicuro (segreto condiviso).

Il motivo per cui le password vengono sottoposte ad hashing è perché il problema non è l'autenticazione, ma l'archiviazione. Se il server venisse compromesso, l'attaccante avrebbe immediatamente accesso a tutti gli account utente poiché ora conoscerebbe 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 una compromissione del 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 hash confrontati con l'applicazione. Sicuramente potrebbero alterare tutti i valori in qualcosa che conoscono, ma questo solleverebbe rapidamente sospetti e il sistema verrebbe spento e protetto.

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

Detto questo, ci sono due cose importanti che l'hashing lato client ti offre. Sebbene non aiuti affatto a proteggere il tuo sistema, può aiutare a proteggere il tuo utente. Se stai trasmettendo la password in modo insicuro o la trasmissione viene compromessa senza che il codice client venga compromesso, proteggerai comunque la password dell'utente (che potrebbe riutilizzare su altri siti) dalla fuga di notizie.

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

In altre parole, fornisce alcune protezioni minori, dal punto di vista del server, l'hash lato client dovrebbe essere trattato come se fosse la password diretta dell'utente. Non fornisce né maggiore né minore sicurezza sul server rispetto a se l'utente avesse fornito direttamente la propria password e dovesse essere protetto come tale.

Se tu voglio 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 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 è 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 per valerne i costi e la complessità.

Se hai alcuni 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 lo fanno t favoriscono l'hashing lato client perché hanno modi migliori per proteggere le informazioni private degli utenti. Pensiamo ai luoghi con potenziali fughe di informazioni e ce ne sono tre:

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

Quindi vediamo perché o perché no l'hashing lato client aiuterà in questi luoghi.

• Il client.

  Se sul tuo computer sono presenti malware, ad esempio, se il tuo browser è compromesso o sul tuo computer è installato un software di registrazione delle chiavi, l'hashing 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, l'hashing lato client può rendere più difficile la fuga di 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 insicuro. 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 fornisce più funzionalità e una migliore sicurezza rispetto all'hashing lato client.

  La conclusione è che l'hashing 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. Invece, memorizzano gli hash delle password in modo che gli hacker non possano ripristinare facilmente le password originali dalle loro informazioni a portata di mano (cioè hash).

  Potresti essere tentato di credere che le cose funzionino ancora bene se il server semplicemente memorizza hash calcolati sul lato client. Ma questo è gravemente sbagliato. In quella situazione gli hash stessi diventano gli equivalenti delle password. L'hacker può passare l'autenticazione semplicemente consegnando l'hash senza annullarlo. L'obiettivo di un hacker non è annullare un hash, ma irrompere nel tuo account. L'importanza risiede nel processo di verifica del server sui dati del client, non sul fatto che i dati siano un valore hash. Pertanto, il vantaggio dell'hash lato client è banale in questo caso e il server deve comunque eseguire un rehash.

Per riassumere, l'hashing lato client è utile in proteggere le informazioni dell'utente, ma la protezione si applica in gran parte al canale di comunicazione. Poiché abbiamo approcci migliori in questo campo (SSL / TLS), l'applicazione dell'hashing lato client è notevolmente superata. Semplicemente non è lo strumento migliore per l'attività da svolgere.

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

Quali vantaggi avrebbe l'hashing della password lato client?

Ebbene, la password non verrebbe inviata in rete in chiaro. Ma dovresti davvero utilizzare la crittografia TLS quando accedi, quindi lo sniffing delle password non dovrebbe essere un problema.

Un altro motivo potrebbe essere che non vuoi che il server mai essere a conoscenza della password degli utenti, nemmeno per un microsecondo. Ciò significa che si fornisce al server l'hash della password al momento della registrazione e quindi si accede 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é neanche il server la conosce).

Dato che stai parlando di applicazione web ...

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

  Password utente- ------- ---------- user1 5f4dcc3b5aa765d61d8327deb882cf99user2 202cb962ac59075b964b07152d234b70user3 098f6bcd4621d373cade4e832627b4f6  

e la nostra funzione di accesso

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

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

Se il tuo processo di hash di accesso è memorizzato nel client, l'attaccante può ancora accedere al tuo account con la password con hash semplicemente collegando il metodo HTTP POST alterando il campo della password da inviare la tua password con hash ed è ancora in grado di accedere. Ricorda che i dati della tua applicazione stanno comunicando con il server tramite il metodo POST alla fine dopo che è stato eseguito un hash per essere confrontati.

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 confronta una password con hash.

In questo caso diciamo che l'attaccante pubblica

$ user = user1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99

Dopo che il lato server ha fatto $ pass = md5.hash (5f4dcc3b5aa765d61d8327deb882cf99 ) restituirà "696d29e0940a4957748fe3fc9efd22a3" che restituisce una dichiarazione falsa.

Questo serve per isolare l'attaccante che ha rubato con successo i dati del database e sta tentando di accedere tramite l'applicazione web utilizzando la password con hash. E, naturalmente, l'attaccante può ancora hackerare gli account se riesce a forzare / crackare con successo gli hash tramite attacchi di 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 un'e-mail agli utenti.

Inoltre viene utilizzato anche per minacce interne come i dipendenti in un impresa. In un'azienda, ci saranno amministratori 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 sostenere che un amministratore di database possa ancora modificare i dati del database attraverso il database stesso, ma non è accessibile dagli sviluppatori ed è più facile individuare da dove proviene l'attacco. Riguarda i diritti di controllo degli accessi e la riduzione al minimo dei rischi e delle minacce.

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

È semplicemente che se si esegue l'hash il prima possibile, si riducono i rischi di programmazione di passare accidentalmente una password in chiaro da qualche parte che non dovrebbe andare. Già adottiamo misure come stringhe sicure e array protetti per cercare di distruggere il testo in chiaro il prima possibile; 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" in C # che richiede la SecureString cancella il testo e l'ha immediatamente 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 quanto di un programmatore qui seduto a guardare una password --- non voglio toccarla! (È ancora una password equivalente in alcuni aspetti, ma almeno è immediatamente nascosta dalla follia come spostare una parentesi di chiusura in una chiamata di metodo concatenata e passare del testo in chiaro nel posto sbagliato. E un array sicuro non è ancora nascosto.)

Salterò qui con il preciso scopo 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 HSTS è implementato, la maggior parte delle persone direbbe che SSLStrip non avrebbe alcun effetto. Giusto? No.

Quando si accede 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 Wireshark / TCPDump ed esportano la chiave privata del server. Ora possono restare in rete per un paio di mesi e per i server ad alto volume (milioni di registrazioni di utenti al mese) ottengono la loro massiccia violazione del testo in chiaro. Ciò presuppone che sia più prezioso acquisire le password per le persone sul servizio che avere RCE sul loro server, ovviamente.

Sul server: vantaggi in termini di prestazioni se non deve essere eseguito bcrypt su ogni password in entrata, che scarica alcuni costi di calcolo sul client senza introdurre nuove vulnerabilità. Questa sembra essere una buona cosa per l'amministratore del tuo server e per i costi dell'hardware.

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

Accetto 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'aggressore 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 cracking delle password, protetto con questi schemi, è economico e veloce. E questo è almeno uno dei problemi principali dell'hashing delle 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 un schema di hashing delle password come Scrypt, Argon2 o Catena per proteggere gli attacchi hardware personalizzati, i requisiti hardware del server aumentano notevolmente. In realtà, i servizi riducono quindi la durezza della memoria o passano a schemi vulnerabili. L'hashing lato client aiuta un po 'a aggirare questo problema. Quando i client calcolano queste costose funzioni (memory hard), il servizio può utilizzarle senza la necessità di un hardware migliore.

I moderni schemi di hashing delle password offrono quindi la possibilità di delegare le parti più costose (memory-hard) della funzione al cliente. Questa funzionalità è chiamata server relief ed è offerta da Argon2 e Catena.

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

Penso che l'hash lato client abbia un lato positivo e uno svantaggio:

pro: nascondi la password in caso di DNS / phishing / qualunque cosa, il che è utile per l'utente, poiché la maggior parte delle persone riutilizza le password su diversi servizi. Come hanno detto altri sviluppatori, questo non fa nulla per la tua sicurezza.

Contro: il tuo server non ottiene la password, il che impedisce cose come avvertire l'utente della forza della password. So che alcuni diranno che questo può / dovrebbe essere lato client, ma quando hai più client, può essere utile centralizzare lato server.

Penso che la probabilità di essere violato sul lato client sia maggiore 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 lato client utilizzati per l'hashing della password possono essere rubati dall'hacker. Non appena i tuoi algoritmi non saranno più un segreto. Penso che sia diventato inutile.