Domanda:
Perché l'hashing lato client di una password è così raro?
Muis
2014-03-18 15:18:54 UTC
view on stackexchange narkive permalink

Ci sono pochissimi siti web che hanno la password degli utenti prima di inviarla al server. Javascript non ha nemmeno il supporto per SHA o altri algoritmi.

Ma posso pensare ad alcuni vantaggi, come la protezione contro fughe di notizie tra siti o amministratori dannosi, che SSL non fornisce.

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

Quali vantaggi pensi ci siano nell'hashing delle password lato client?
@TimLamballais Un client tipico può dedicare molto più tempo all'hashing di un server. Quindi, se hai un'implementazione ad alte prestazioni nel client (che esclude javascript nei browser attuali) puoi usare hash delle password più costosi e quindi più forti. Significa anche che il server non vede mai la password stessa. L'hashing lato client è anche un prerequisito per i protocolli PAKE aumentati come SRP in cui impersonare il server non ti dà accesso alla password.
Javascript non è più così lento. I moderni motori javascript sono diventati così veloci da essere alla pari con i linguaggi compilati e le aggiunte recenti come gli array digitati forniscono gli strumenti adeguati per il calcolo dei numeri richiesto dalla crittografia.
@TimLamballais Un vantaggio sarebbe che il server non vede mai la mia vera password e non può farla trapelare (sì, possono ancora trapelare l'hash, ma dovrebbe essere salato dal nome del dominio, quindi inutile per l'accesso ad altri siti). Ma per il più grande vantaggio vedere il mio commento alla risposta di Phillip.
Molte persone si chiedono se con questa pratica si ottiene una maggiore sicurezza. Una cosa che fa è ridurre il rischio. Se esegui sempre l'hash o la crittografia (ho visto steam / valve crittografare con una chiave pubblica e scommetto che non stanno decrittografando) non c'è alcuna possibilità che tu abbia mai un'imbarazzante culatta del testo in chiaro. No ... non è più sicuro ma non è inutile
WPA2-PSK utilizza l'hashing della password lato client per l'autenticazione.
Undici risposte:
#1
+60
paj28
2016-11-29 15:39:09 UTC
view on stackexchange narkive permalink

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 .

E se _il server fosse stato compromesso_ da un cracker e volesse raccogliere semplici password dai client per usarle in altri posti?Nessuna salvaguardia ma hashing lato client.Perché dobbiamo costringere i client a fidarsi del server?
@ КонстантинВан - fai riferimento alla parte "server compromesso" della risposta
Un altro svantaggio dell'hashing lato client è che non è possibile applicare criteri per le password sul server.Fondamentalmente non è possibile convalidare che la password selezionata dall'utente sia abbastanza forte
@Michael Questa è una buona cosa secondo me, poiché le politiche sulle password sulla maggior parte dei server sono ridicole.Molti caratteri della password sono vietati senza motivo.
#2
+51
AJ Henderson
2014-03-18 18:36:31 UTC
view on stackexchange narkive permalink

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à.

Ho bisogno di crittografare alcuni dati lato client e inviando solo l'hash al server, posso provare che il server non può decrittografare i dati locali, poiché non conosce la password in testo normale. Inoltre, quando salate l'hash con il nome di dominio, c'è una garanzia che il server non potrà mai far trapelare la mia password, solo un hash salato (inutile).
@Muis il mio punto è che l'hashish salato non è inutile. Può compromettere l'integrità del tuo sistema di autenticazione in quanto è la nuova password per l'autenticazione (anche se non per la crittografia). L'aggressore potrebbe comunque ottenere l'hash dal DB sul server e convincere il server di essere l'utente e accedere alla copia crittografata dei file (cosa che concessa, potrebbe avere accesso comunque già a quel punto). Inoltre, un sale dovrebbe essere univoco a livello globale, non un nome di dominio.
@Muis: il punto è semplicemente che dovresti trattare il lato client generato dall'hash come se fosse la password dell'utente quando lo gestisci lato server. Non è male usare un hash lato client per proteggere la password dell'utente dall'essere esposta al server, ma praticamente agisce come la password diretta dell'utente per quanto riguarda il server.
La mia preoccupazione principale è che la password trapelata possa essere utilizzata per accedere ad ALTRI siti, dove il cliente ha utilizzato la stessa combinazione nome utente / password. Ciò verrà evitato aggiungendo il nome del dominio all'hash (poiché non posso memorizzare un valore univoco in modo persistente in javascript).
@muis il sale non deve essere protetto. Memorizzalo sul server e invialo al client prima dell'hashing. Se il server non può essere considerato attendibile per questo, utilizzare ancora il nome di dominio e il nome utente aggiunti ai dati forniti dal server, forse.
Allora perché non fare entrambe le cose?Hash sul lato client per evitare di far trapelare la password effettiva in chiaro e di nuovo hash sul lato server per evitare il problema dell'hash che diventa la password.
@xaser: potresti, ma non aggiungerebbe molto.Questo è fondamentalmente ciò di cui io e Muls abbiamo parlato nei commenti.Ha effetto solo se hai un uomo nel mezzo che può solo osservare (altrimenti potrebbero spogliare l'hashing lato client) e fa la differenza solo se il sale è globalmente unico (non può essere presentato con arcobaleno) e la passworddi per sé è abbastanza sicuro da resistere alla forza bruta con un cracker di hashish.Non protegge il sito stesso poiché l'hash lato client È la password dell'utente per quel sito e protegge solo le password condivise (che comunque sono cattive).
L'hashing sul lato client e sul lato server non fornisce una sicurezza altrettanto efficace quanto l'utilizzo di SSL / TLS per trasmettere le password in chiaro.Se non ancora più sicuro se questi protocolli dovessero essere violati?La lunghezza non è considerata qui, le password complesse potrebbero essere un requisito se necessario @AJHenderson
@uhfocuz No. Niente affatto, per molte ragioni.Il problema principale è che ai fini dell'accesso, l'hash lato client sarebbe la password dell'utente, non qualunque cosa l'utente digiti, poiché il server non può verificare cosa ha fatto il lato client.Inoltre, senza la protezione sul canale che fornisce il contenuto della pagina, un uomo nel mezzo potrebbe semplicemente rimuovere completamente l'hash lato client e catturare la password dell'utente.Infine, anche senza questi problemi, a meno che la password non rappresenti lo stesso grado di entropia della chiave utilizzata in SSL, sarebbe più facile forzare una collisione hash.
@AJHenderson e se "hash è la password dell'utente" fornisse un mezzo più sicuro e due algoritmi di hashing completamente separati fossero usati sul lato client e server.E solo per placarti, SSL viene utilizzato anche qui.Sarebbe una buona dinamica per l'hashing lato client sicuro, mantenendo allo stesso tempo la natura dell'hash archiviata in modo sicuro sul lato server.
@uhfocuz questo è il mio punto.Non fornisce un supporto più sicuro.Due diversi algoritmi di hashing non contano davvero.Non ho mai detto che non potresti fare un hash lato client, solo che la natura di un hash lato client non ti offre davvero nulla in termini di sicurezza.Protegge solo un utente che utilizza la stessa password complessa in più di un posto dall'invio della password al server.Questo è un vantaggio molto limitato per un bel po 'di lavoro e un potenziale aumento della superficie xss.
@AJHenderson Sono ancora fortemente contrario alla tua affermazione che ciò fornirebbe un vantaggio molto limitato, raddoppierebbe i tempi di bruteforcing, mai la vera password potrebbe essere facilmente divulgata nello scenario i nostri protocolli HTTPS sono già infranti e XSS, no, manomissione, sì maquesti dati provengono dalla registrazione, sarebbero efficaci tanto quanto l'utilizzo di dati di manomissione
@uhfocus non avrebbe alcun impatto sul tempo di forza bruta che le corse extra lato server non avrebbero e non fornisce alcun vantaggio al sito che lo implementa poiché l'hash lato client è irrilevante per l'autenticazione.Se ssl si rompe, il sistema non offre alcun vantaggio poiché non fornisce alcun controllo di integrità o autenticazione del server.L'unico vantaggio che offre è quello che ho descritto.Se fornisse ciò che descrivi sarebbe fantastico, ma non è così.
Possiamo continuare a discuterne in chat [qui] (http://chat.stackexchange.com/transcript/message/31963600#31963600) se vuoi.
@AJHenderson Non penso che vorresti che il server inviasse il sale al client.Salt aiuta a proteggersi dall'approccio del fucile da caccia, determinando la password per molti utenti contemporaneamente, se il database è compromesso.Non aiuta a difendersi da un attacco contro un singolo utente.Far trapelare pubblicamente il sale di un utente a chiunque tenti di accedere con quel nome utente ridurrebbe leggermente la sicurezza complessiva.
@lordcheeto come?Senza i dati del database, non è possibile un attacco offline.Avere il sale senza hash è di valore zero per un attaccante.Questo è il motivo per cui il sale non è considerato un dato sicuro.Il DB deve saperlo e se l'aggressore non ha il DB (o almeno l'hash), è un'informazione completamente inutile.Se il client stesso è compromesso, possono semplicemente registrare le chiavi.
"* Se il server venisse compromesso, l'attaccante avrebbe immediatamente accesso a tutti gli utenti *" Woa, grande sorpresa!Qualcuno che possedeva il server può effettivamente accedere alle cose sul server!Sarcasmo a parte, sento che questa risposta non evidenzia le cose giuste.Certo, si dovrebbe fare un hash veloce sul server, ma perché altrimenti ci preoccupiamo di hash e sali lenti se non per la protezione dell'utente?L'hashing lato client ha [molti vantaggi] (https://security.stackexchange.com/a/201099/10863) e ritengo che impedire un accesso sia un piacevole effetto collaterale che non è affatto essenziale per la sicurezza del sistema.
@Luc: non tutte le violazioni implicano il controllo totale.Se si accede solo alla tabella utente in modalità di sola lettura, tutti gli utenti verrebbero violati completamente.Se l'hashing è sicuro lato server, ci sarebbe ancora uno sforzo considerevole per utente per poter compromettere ulteriormente il sistema.Forse è stato compromesso solo un server di backup offline o è stato rubato un backup su un laptop di sviluppo.È sciocco aspettarsi solo violazioni di tutto o niente.Un hash lato client lento viene banalmente ignorato poiché il lato client può essere ignorato e inserire semplicemente il risultato che il server si aspetta.
@Luc - nota che in realtà sono d'accordo con la tua risposta sull'altra domanda in quanto si tratta di un'applicazione.Nel caso di un'applicazione, è almeno leggermente più difficile bypassare l'hashing aggiuntivo per saltare direttamente alla password intermedia, quindi c'è un certo valore, ma questa domanda si riferiva specificamente ai siti Web in cui è banale saltare alla password intermedia.Tutto l'hashing lato client per un sito Web è creare una password derivata da password e un hash lento non è più efficace di un hash rapido lato client o di una chiave derivata da password.
@AJHenderson Essendo banale saltare alla password intermedia, intendi che un utente malintenzionato modificherebbe semplicemente il codice del server per impedirgli di inviare il JavaScript necessario al client, in modo che il client invii la password invece?In tal caso, vedi le FAQ in fondo, è un argomento che vedo spesso e non penso sia sufficiente per negare tutti i vantaggi.
@Luc: le tue FAQ sono sbagliate quando si tratta di siti web.I commenti non sono un ottimo posto per discussioni estese, ma per essere brevi e lenti l'hashing è importante SOLO se gli hash sono compromessi (quindi il DB è compromesso) se il server non è compromesso, le cose potrebbero anche essere in testo semplice quanto a lungopoiché la crittografia del canale è in atto.Il punto su un'estensione del browser è del tutto irrilevante in quanto l'attaccante non sta attaccando la macchina dell'utente, ma piuttosto il livello web.Le possibilità di avere un'incursione limitata, specialmente quando c'è un IDS decente, sono in realtà piuttosto alte.
Se le cose che non dovrebbero essere scritte nel DB iniziano a scrivere nel DB, qualcosa si noterà, ma ci sono molti modi possibili in cui leggere solo gli elenchi hash potrebbero essere esfiltrati.Sarebbe quindi possibile iniziare a lavorare sulla compromissione degli account per modificare le cose nel sistema o cercare le credenziali corrispondenti su altri servizi.Questo è il caso molto più realistico e l'hashing lato client non aiuterà molto.Ha valore per l'estensione della password, ma questo è tutto ciò che sta davvero ottenendo.
#3
+22
Cyker
2016-11-29 16:21:54 UTC
view on stackexchange narkive permalink

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.

Ri: questa dichiarazione: "L'obiettivo di un hacker non è annullare un hash, ma irrompere nel tuo account".Direi che dipende da cosa è il sito.Spesso la password dell'utente è più preziosa dell'accesso al sito, con la speranza che la password possa essere utilizzata su altri siti in cui ottenere l'accesso avrebbe più valore.
@TTT Dal suo contesto, questa frase in realtà significa che l'hacker non si preoccupa se si tratta di un hash o di una password in chiaro fintanto che ottiene le informazioni private che desidera.
Questa risposta è molto utile.
Sono d'accordo con TTT.Non sono d'accordo sul fatto che sia "meglio" (come hai detto tu) che il client invii la propria password in chiaro invece di un hash salato.Ciò espone al rischio che qualche agente lato server rubi o divulghi la password del client, per intento doloso o negligenza.Poiché molti utenti riutilizzano la password cross-side, è un rischio molto preoccupante.
Quindi la sintesi della tua risposta è "perché vedo solo piccoli vantaggi"?Non perché ci sono degli svantaggi nel fare solo un hash veloce sul server e l'hash lento sul client?Ho approfondito un po 'l'argomento in [questa risposta] (https://security.stackexchange.com/a/201099/10863) e sono curioso di sentire i tuoi pensieri.
@Luc L'idea è che il server utilizzi tutto ciò che è passato dal client come prova di identità, che si tratti di un hash o meno.Il server la vede semplicemente come una stringa semplice e il server deve svolgere il proprio lavoro per proteggere questa stringa dal ripristino da parte del malintenzionato.Se il client ritiene di dover proteggere la propria password da un server dannoso o da un canale di comunicazione vulnerabile, è libero di farlo.Ma non è compito del server web.Ad esempio, il client può utilizzare una password casuale per ogni sito e non è necessario alcun hashing.
@Cyker Sì, se tutti usassero un gestore di password con password uniche e casuali, non dovremmo avere questa discussione!Ma non è così, sappiamo tutti quanto spesso i siti vengono violati e che i dati vengono utilizzati per hackerare gli utenti su altri siti, dove hanno riutilizzato la loro password.In effetti non è tuo compito proteggere l'utente, ma non è nemmeno tuo compito riparare l'acqua in Africa.Tuttavia, i paesi che possono permetterselo pagano gli aiuti allo sviluppo (e nei paesi democratici, le persone concordano collettivamente su questo).Aiutiamo altre persone dove possiamo, quindi se possiamo semplicemente fare l'hashish in un posto migliore, perché no?
@Luc Per * hash in un punto migliore *: cosa ti fa pensare che l'hashing sul lato client sia migliore che sul lato server se il canale è sicuro?Se stai usando un semplice HTTP, dovresti passare a HTTPS invece di fare affidamento sul tuo hashing lato client.
@Cyker Vedi il link che ho pubblicato in precedenza: https://security.stackexchange.com/a/201099/10863 Ci sono molti vantaggi nell'hash lato client, tutti presuppongono che il canale di trasporto sia sicuro (mi hai appena ricordato che ioho dimenticato di menzionare il caso in cui il canale di trasporto è compromesso!).A proposito, sono pienamente d'accordo sul fatto che https sia molto più importante dell'hashing lato client.Se non hai https, ci sono problemi molto più grandi.
@Luc Bene, se ritieni che l'hashing lato client sia utile nel tuo caso d'uso specifico, sei libero di implementarlo.A condizione che tu stia utilizzando un algoritmo di hashing sano, non vedo come diventi dannoso se non sprecando alcune risorse sulla macchina client.Ad esempio, se ritieni che la macchina client sia più sicura della macchina server perché ci sono alcuni dipendenti inaffidabili che intercettano i dati degli utenti sul lato server.Non dimenticare di salare l'hash in quel caso.
@Cyker Salatura, sì, grazie per avermi ricordato di aggiungerlo.La gente infatti non dovrebbe dimenticarsi di farlo.
#4
+7
Mayhem Software
2015-05-05 12:36:57 UTC
view on stackexchange narkive permalink

È 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à.

Questa risposta non fornisce nulla che le altre risposte non facciano e non coglie il punto che per un MitM, l'hash della password del client può essere utilizzato come se fosse la password stessa.
@Mark Um no Mark. Questo effettivamente aiuta con mitm. Mayhem sta affermando di eseguire nuovamente l'hashing della password.
Questa è una buona idea a cui non ho pensato.Hash sul lato client per nascondere la password in testo normale, quindi hash sul lato server per proteggersi da una violazione del lato server.Grazie per la condivisione!
@Karl, L '"uomo al centro" fornirebbe comunque gli stessi parametri di richiesta dell'utente di destinazione.Solo perché non è una password, non significa che l'attaccante non possa intercettare l'hash e fornire lo stesso hash al server (per lasciare che "hash l'hash" e abbia successo in una partita).
@RedGlobe Questo però è vero.Ma aiuta, perché un sacco di utenti di Internet usa la stessa password per tutto.Sono d'accordo che potrebbe non aiutare contro quel particolare sistema, ma aiuterà su scala più ampia.
#5
+6
Philipp
2014-03-18 17:12:43 UTC
view on stackexchange narkive permalink

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).

Il vantaggio per me sarebbe che posso utilizzare la password dell'utente per crittografare alcuni dati locali nella mia app e provare che il server non è mai in grado di decrittografare quei dati (poiché conosce solo l'hash). Altrimenti avrei due richieste all'utente finale per due password diverse (1 per l'accesso, 1 per la crittografia).
@Muis In quel caso la risposta sarebbe "Perché nessuno ha requisiti così esotici come te".
@Muis, la tua definizione di "prova" deve essere debole poiché spesso la conoscenza dell'hash equivale alla conoscenza della password poiché gli attacchi al dizionario hanno molto successo. Però vedo il tuo punto. È una prova se l'utente sceglie una buona password.
@mikeazo Salgo l'hash, quindi gli attacchi del dizionario sono inutili.
@Muis Non è così che funziona la salatura. I sali proteggono solo dalle tabelle arcobaleno precalcolate, non dagli attacchi dei dizionari.
@Philipp, salt protegge dagli attacchi del dizionario in cui l'attaccante vuole solo uno dei tanti hash catturati. Non aiuta contro gli attacchi del dizionario su un singolo hash.
@muis in tal caso utilizza una chiave simmetrica privata protetta da password.Ciò fornirà generalmente una sicurezza di gran lunga migliore per i dati crittografati a causa della maggiore entropia della chiave simmetrica, garantendo anche che il server non abbia la capacità di decrittografare (poiché non ha la chiave privata).Non lanciare il tuo ... usa schemi sicuri stabiliti e conosciuti.
@Muis L'utilizzo della password utente per crittografare i dati locali potrebbe non essere buono come pensi.Cosa succede se l'utente cambia la sua password?Inoltre, se il server ha i dati per crittografarlo con la password utente, il server non ha bisogno di decrittografare i dati, li ha già, quindi non puoi provare che il server non sia in grado di accedere ai datiè il punto di decrittarlo)
-1 risposta molto miope.Certo, ciò che trasmetti al server è equivalente alla tua password.È sempre così.Ma protegge l'utente molto meglio da hash prima della trasmissione (TLS ha la sua parte di problemi) e soprattutto prima che arrivi sul server (dove di solito si verificano le vere vulnerabilità).
#6
+3
Sky
2014-03-18 18:56:40 UTC
view on stackexchange narkive permalink

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

nell'applicazione web

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.

Hai ragione sul fatto che non rende più difficile per un utente malintenzionato accedere al MIO sito utilizzando l'hash rubato, ma rende più difficile accedere a UN ALTRO sito, poiché l'altro sito molto probabilmente non utilizza esattamente lo stesso algoritmo di hash salt +.
Non è possibile che l'aggressore possa accedere a UN ALTRO sito con la password con hash a condizione che l'ALTRO sito Web non si eserciti con l'hashing nel client ed è una buona password che è difficile da essere bruteforce con il dizionario o gli attacchi alla tabella arcobaleno. E come sviluppatore, perché mai dovresti preoccuparti di "UN ALTRO" sito in primo luogo. Se gli utenti apprezzano molto gli altri dati, dovrebbero esercitarsi a non utilizzare invece una password globale.
#7
+3
Steven Coco
2018-01-21 13:15:54 UTC
view on stackexchange narkive permalink

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.)

#8
+1
DeepS1X
2017-05-08 07:36:50 UTC
view on stackexchange narkive permalink

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.

Sono curioso di sapere perché qualcuno ha svalutato questa risposta.SSLStrip è un po 'datato, ma non sbagliato, e il resto della risposta mi sembra accurato.
Di certo non lo so.Rileggendo il mio commento di diversi anni fa, non riesco a vedere alcun difetto evidente nel mio ragionamento.
#9
+1
BeloumiX
2019-01-10 14:19:25 UTC
view on stackexchange narkive permalink

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 .

#10
-1
savvy
2016-11-29 14:29:35 UTC
view on stackexchange narkive permalink

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.

(Non ho votato negativamente, sarebbe carino se le persone potessero spiegare i voti negativi.) Il consiglio sulle password dovrebbe essere fatto sul lato client.Consiglierei una libreria come [zxcvbn] (https://github.com/dropbox/zxcvbn) che è disponibile in molte lingue diverse e sembra molto orientata agli obiettivi e ben progettata.Ciò limiterebbe anche la necessità di incorporare separatamente i consigli nel codice di tutti i clienti.
#11
-5
Li Billy
2014-03-18 15:42:11 UTC
view on stackexchange narkive permalink

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.

Generalmente disapproviamo l'algoritmo segreto (vedi [Principio di Kerckhoffs] (http://en.wikipedia.org/wiki/Kerckhoffs's_principle) e security-through-obscurity. L'hashing delle password non ha certo bisogno di fare affidamento su questo. Al massimo applichiamo una chiave e speriamo che l'aggressore non la trovi anche se riesce a rubare il database.
L'argomento "il server è più sicuro" ha poco senso in questo contesto. 1) Il client conosce la password in chiaro, quindi un trojan può banalmente rubarla con un key-logger. 2) L'hashing delle password offre un vantaggio rispetto alle password in chiaro solo quando il server viene violato e il database viene rubato.
danke, CodesinChaos. mi hai offerto una lezione utile gratuitamente.
inoltre, scusami, ho trovato il tuo twitter abbastanza informativo. ti dispiacerebbe se ti seguissi lì?
Il modo in cui funziona Twitter è che segui le persone i cui tweet trovi interessanti. Non serve chiedere il permesso.
grazie u, seguito.
Un server con tutti i suoi dati utente è un obiettivo molto più prezioso di un singolo utente.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...