Perché quasi nessuna pagina web ha le password di hash nel client prima di inviarle (e cancellarle di nuovo sul server), in modo da "proteggere" dal riutilizzo delle password?

46

Esistono molti siti su Internet che richiedono informazioni di accesso e l'unico modo per proteggersi dal riutilizzo delle password è la "promessa" che le password siano sottoposte a hash sul server, il che non è sempre vero.

Quindi mi chiedo, quanto è difficile creare una pagina Web con hash delle password nel computer client (con Javascript), prima di inviarle al server, dove verrebbero ricodificate? In teoria ciò non fornisce alcuna sicurezza aggiuntiva, ma in pratica può essere utilizzato per proteggere da "siti non autorizzati" che non hanno la password nel server.

— Martín Fixman
fonte

18

una password con hash inviata in chiaro non è migliore di una password inviata in chiaro se il server sta solo confrontando gli hash, l'uomo nel mezzo degli attacchi ama questo tipo di "sicurezza"

3

La migliore soluzione è (imo) un gestore di password lato client. In questo modo, puoi generare una stringa casuale di caratteri come password e non ti affidi al server per "proteggerti".

— Dean Harding,

2

@Jarrod - mi sembra, tuttavia, che siti Web diversi che utilizzano algoritmi di hashing sul lato client diversi impedirebbero l'attacco descritto da quel fumetto. Una password ampiamente riutilizzata diventa molte password diverse attraverso quei diversi algoritmi di hash. Il calcolo dell'hash sul lato client non impedisce l'applicazione di altri tipi di sicurezza, come l'invio dell'hash tramite una connessione protetta.

— Steve314,

2

@ Steve314 il mio punto è che qualsiasi cosa sul client è compromessa per impostazione predefinita. Puoi hash e hash e hash, se viene fatto sul client e passato avanti e indietro al server in quel clearpunto è solo una masturbazione matematica a quel punto. Ho dovuto riparare un sistema che ho ereditato, progettato esattamente come tu e l'OP descrivete, è stato costantemente violato da adolescenti con Wireshark. L'abbiamo bloccato solo quando abbiamo inserito la REALcrittografia e crittografato e firmato tutti i payload da e verso il server, la manipolazione dell'account si è fermata e non è più avvenuta dopo.

5

Sembra che il tuo piano per proteggerti dai siti canaglia sia quello di chiedere ai siti canaglia di creare una migliore sicurezza. ?

— pc1oad1etter

46

Perché non è usato? Perché è un sacco di lavoro extra per guadagno zero. Un tale sistema non sarebbe più sicuro. Potrebbe anche essere meno sicuro perché dà la falsa impressione di essere più sicuro, portando gli utenti ad adottare pratiche meno sicure (come il riutilizzo delle password, le password del dizionario, ecc.).

— Rein Henrichs
fonte

2

Questa è la risposta migliore finora.

1

È come la crittografia Blu-Ray e DVD. Non richiede nemmeno una chiave per sbloccare. L'unica "protezione" fornita era che quando i DVD uscivano per la prima volta costava di più acquistare un disco per copiarlo che acquistare una copia completa del film. Ovviamente ora puoi acquistare un dvd per un dollaro e ancora di più è il fatto che le chiavi sono ora di dominio pubblico. Lo stesso sta accadendo con Blu-Ray

— Michael Brown,

2

Penso che l'hashing di una password lato client aggiunga sicurezza. Se ascolto, vedo solo il tuo hash, non la tua password. Se il server invia una sfida (come dovrebbe) l'hash non è nemmeno riutilizzabile.

— Andomar,

2

Penso che l'approccio di x4u potrebbe benissimo essere appropriato per alcune applicazioni in cui i requisiti di sicurezza sono da qualche parte tra la trasmissione di password sul filo e l'uso di certificati. Penso che alcuni dei neo-esperti stiano trascurando il fatto che l'hash della password prima che venga trasmessa venga eseguita oltre alla gestione delle credenziali lato server standard. Quindi la domanda è questa: la proposta di x4u migliora la sicurezza nello scenario di trasmissione della password sul filo o no. Lo dico io. La chiave per rendersene conto risiede nell'uso di sali per password.

— LOAS,

6

Il modo corretto per prevenire gli attacchi MITM è la crittografia end-to-end. TLS (https) esiste: usalo. Non inventare i tuoi schemi crittografici.

— Rein Henrichs,

14

In teoria ciò non fornisce alcuna sicurezza aggiuntiva, ma in pratica può essere utilizzato per proteggere da "siti non autorizzati" che non hanno la password nel server.

Come ti protegge esattamente? Sembra che tutto ciò che vuoi fare è hash la password con hash che è in qualche modo inutile. Perché la password con hash diventerebbe quindi la password.

Esistono molti siti su Internet che richiedono informazioni di accesso e l'unico modo per proteggersi dal riutilizzo delle password è la "promessa" che le password siano sottoposte a hash sul server, il che non è sempre vero.

Che ne dici di non usare la stessa password per più di un sito. Il motivo per cui i siti Web hanno la password in teoria è impedire l'accesso al tuo account se LORO sono compromessi. L'uso della stessa password per più siti Web è semplicemente stupido.

Se hai usato JavaScript, tutto ciò che "l'hacker" dovrebbe fare è usare lo stesso metodo nelle password con hash con hash. Una volta che hai le informazioni di hash è giusto il tempo che serve per calcolare la password-> stesso hash nel database che è un fattore che impedisce l'accesso a un account.

— Ramhound
fonte

1

Se il tuo browser esegue sempre l'hashing allo stesso modo, sì, l'hash può essere utilizzato come password ovunque. E se i browser assegnassero un salt in base al sito (forse il dominio?) Prima di eseguire l'hashing e inviarlo al sito? Penso che sia un'idea interessante.

— Tesserex,

2

se è sul client, è compromesso, qualsiasi sale sul client è in bella vista, questa è una domanda illogica. se non capisci la risposta di @ Ramhound non dovresti scrivere codice che deve essere sicuro e iniziare a leggere su sicurezza e crittografia dall'inizio.

3

Quando si sta citando il manifesto originale, si prega di formattare il testo in quanto tale (selezionare il testo e utilizzare l'icona citazione appena sopra l'editor)

— Marjan Venema

1

Jarrod, segui i tuoi consigli e informati un po 'prima di fare affermazioni ridicole. Un uomo nel mezzo dell'attacco è inutile contro funzioni di hash sicure con ragionevole lunghezza di sale. E il mio suggerimento non è in alcun modo "sicurezza per oscurità", in realtà è sicuro in base a ciò che è attualmente noto e accettato dagli esperti in questo campo e viene utilizzato allo stesso modo in molti protocolli. Non è una mia invenzione, ho appena applicato una procedura ben compresa al login di un sito web. I tuoi falsi presupposti non ottengono alcuna sostanza dal fatto che sono ovviamente condivisi anche da molti altri.

— x4u,

3

Se il salt è conosciuto dal client e viene inviato in chiaro da un server, anche qualsiasi cosa nel mezzo lo sa. Non ho mai detto, avevo bisogno di annullare l'hash, se conosci il sale sul client, quindi non è sicuro.

11

Perché aggiungerebbe poco o nessun valore. Il motivo per cui l'hash è che se il tuo database viene violato, l'hacker non avrebbe un elenco di password valide, ma solo hash. Pertanto non potevano impersonare alcun utente. Il tuo sistema non è a conoscenza della password.

Sicuro proviene da certificati SSL più una qualche forma di autenticazione. Voglio che i miei utenti forniscano una password in modo da poter calcolare l'hash da essa.

Inoltre, l'algoritmo di hashing sarebbe sul server in un'area più sicura. Mettendolo sul client, è abbastanza facile ottenere il codice sorgente per Javascript, anche se i suoi file di script di riferimento nascosti.

— Jon Raynor
fonte

3

Questa è la risposta migliore È necessario crittografare a livello di trasporto. Senza farlo, il resto non è sicuro. Sì, potresti scrivere una funzione di crittografia ... ma tale funzione sarebbe visibile agli utenti (dannosi). Usa SSL.

— pc1oad1etter

La sicurezza di un algoritmo di hashing non dovrebbe dipendere dal fatto che sia segreta. Gli algoritmi di hash per la sicurezza dovrebbero essere funzioni a senso unico: anche se si dispone del codice, è difficile annullarlo. Al contrario, dovresti usare una nota libreria di hash progettata solo per le password. Se non è noto, è quasi certamente difettoso o mal riposto.

— leewz,

6

La soluzione è più semplice di così. Certificati client. Creo un certificato client sul mio computer. Quando mi registro su un sito Web, facciamo una stretta di mano usando il mio certificato client e il certificato del server.

Nessuna password viene scambiata e anche se qualcuno hackera il database tutto ciò che avrà sarà la chiave pubblica del mio certificato client (che dovrebbe essere salato e crittografato dal server per un ulteriore livello di sicurezza).

Il certificato client può essere archiviato su una smart card (e caricato in un deposito online sicuro utilizzando una password principale).

Il bello di tutto è che elimina il concetto di phishing ... non stai mai inserendo una password in un sito web, stai solo stringendo la mano con quel sito web. Tutto ciò che ottengono è la tua chiave pubblica che è inutile senza una chiave privata. L'unica suscettibilità è trovare una collisione durante una stretta di mano e che funzionerebbe solo una volta su un singolo sito Web.

Microsoft ha provato a fornire qualcosa del genere in Windows con Cardspace e in seguito lo ha presentato come standard aperto. OAuth è in qualche modo simile ma si basa su una "parte emittente" intermediata. Le InfoCard invece potrebbero essere auto-emesse. Questa è la vera soluzione al problema delle password ... rimuovendo completamente le password.

OAuth è un passo nella giusta direzione però.

— Michael Brown
fonte

5

Sebbene i certificati client siano un approccio ragionevole per alcuni casi d'uso, non sono qualcosa che può essere aggiunto facilmente a un accesso al sito Web. Richiedono una grande collaborazione da parte degli utenti e dipendono dalla sicurezza della chiave privata degli utenti. L'uso di una chiave privata può essere sicuro o conveniente, ma non entrambi contemporaneamente.

— x4u,

5

la maggior parte delle risposte qui sembra mancare completamente il punto di hashing della password lato client.

il punto non è proteggere l'accesso al server a cui si sta effettuando l'accesso, poiché l'intercettazione di un hash non è più sicura dell'intercettazione di una password in testo semplice.

il punto è davvero proteggere la password dell'utente , che di solito è molto più preziosa dell'accesso al singolo sito poiché la maggior parte degli utenti riutilizzerà la propria password per più siti (non dovrebbero, ma la realtà è che lo fanno quindi non dovrebbe essere sventolata) ).

ssl è ottimo per la protezione dagli attacchi mitm, ma se un'applicazione di accesso è compromessa sul server, ssl non protegge i tuoi utenti. se qualcuno ha ottenuto maliziosamente l'accesso a un server Web, sarà probabilmente in grado di intercettare le password in testo semplice perché nella maggior parte dei casi le password sono codificate solo da uno script sul server. quindi l'attaccante può provare quelle password su altri siti (di solito più preziosi) usando nomi utente simili.

la sicurezza è una difesa approfondita e l'hash sul lato client aggiunge semplicemente un altro livello. ricorda che mentre proteggere l'accesso al tuo sito è importante, proteggere la segretezza delle password dei tuoi utenti è molto più importante a causa del riutilizzo delle password su altri siti.

— crutchy
fonte

2

La risposta accettata condivide abbastanza bene il tuo punto. Anche se "la maggior parte delle risposte" non lo è e poiché la tua risposta non aggiunge molto valore, non ha senso resuscitare questa domanda.

— Frank

è probabilmente più un commento che una risposta (mi scuso per non aver capito come aggiungere al thread del commento di risposta accettato), e anche se il mio punto è condiviso nella risposta accettata, a quanto pare non era abbastanza chiaro poiché le risposte sembrano a spazzolarlo ancora. grazie per il feedback

— stampella

@Francare la risposta accettata è troppo lunga per disturbare la lettura. entra troppo nel dettaglio di come questo può essere implementato e sfiora i benefici verso la fine. Avere un TL; DR in una risposta diversa è vantaggioso.

— Jules,

2

@Jules: ecco perché esiste la modifica.

— Robert Harvey,

1

@JarrodRoberson Penso che non stai confondendo più sicuro con insicuro ? Se si verifica MITM, l'accesso al sito è già rinunciato, no? A meno che non si utilizzi il certificato client anziché la password, che sarebbe eccessivamente complesso per gli utenti ordinari. Dal mio punto di vista, l'hash sul lato client impedisce che la stessa password venga compromessa su altri siti, supponendo che ciascun algoritmo di hashing sia unico. Potrebbe non essere più sicuro, ma non è nemmeno meno sicuro in alcun modo? Quindi perché ti impegni così tanto? Mi sono imbattuto in questo da meta, e questa è la migliore risposta che vedo finora.

— zypA13510,

1

È sicuramente possibile e in realtà non è necessario attendere un sito Web.

Dai un'occhiata a SuperGenPass . È un bookmarklet.

Riconosce semplicemente i campi delle password, concatena ciò che si digita con il dominio del sito Web, l'hash, lo manipola in qualche modo in modo da ottenere solo caratteri "ammessi" nella password, e solo allora la tua password hash viene inviata sul filo.

Utilizzando il dominio del sito nel processo, si ottiene così una password univoca per sito, anche se si riutilizza sempre la stessa password.

Non è estremamente sicuro (base64-MD5), ma se lo desideri distribuisci perfettamente un'implementazione basata su sha-2.

L'unico aspetto negativo è se il dominio cambia, nel qual caso dovrai chiedere al sito web di reimpostare la password perché non sarai in grado di recuperarla da solo ... non succede spesso, quindi lo considero un compromesso accettabile.

— Matthieu M.
fonte

Questo è quello che stavo pensando quando ho letto la domanda; è praticamente inutile che i siti eseguano il loro hash lato client, ma un'estensione del browser che lo fa (usando un po 'di sale basato sul dominio) annullerebbe efficacemente i rischi associati al riutilizzo della password. Certo, la parte divertente arriva quando provi ad accedere da un'altra macchina ...

— Aaronaught,

3

questo non è più sicuro di qualsiasi altro schema che passa la password in chiaro. Rende la password unica ma non è ancora crittografata , ma se ho un server nel mezzo, posso solo prendere la password complicata ma ancora chiara e usarla quanto voglio, non cambia. Un hash non è un proiettile magico, non è nemmeno crittografia, sono chiamati hash crittografici, ma ciò non significa che siano crittografia. Non importa se la mia password è passworde o un SHA-256 passwordcon un po 'di sale che è noto al client, un uomo nel mezzo allegato può catturarla.

@Jarrod Roberson: puoi ovviamente usare la password, ma non puoi riutilizzarla per un altro dei miei account, questo è il punto. Pertanto, se uno dei siti Web a cui mi collego viene rubato la sua base di password e li memorizza in chiaro, gli altri miei account sono al sicuro.

— Matthieu M.,

@Aaronaught: ecco dove brilla davvero. Poiché la password inviata deriva esclusivamente dal dominio del sito Web a cui si accede e da una password principale di propria scelta, è possibile accedere da qualsiasi computer (e browser) purché si disponga del bookmarklet. Ecco perché è leggermente più comodo di un certificato.

— Matthieu M.,

6

@Jarrod: questa non è una misura di sicurezza per il sito , è una misura di sicurezza per l' utente . Se tutti usassero uno schema come questo, il riutilizzo della password sarebbe un problema. Uno schema MITM potrebbe utilizzare la password con hash del client per ottenere l'accesso a quel sito, ma solo a quel sito. Ecco dove sta il miglioramento. Normalmente ti aspetteresti di poter accedere a molti account semplicemente rompendo una password, perché è probabile che quella password venga riutilizzata; in questo caso, la password crackata è praticamente garantita per essere valida solo per il sito o il database in cui è stata trovata.

— Aaronaught,

0

Mi piace la risposta di X4u, ma a mio avviso qualcosa del genere dovrebbe essere integrato nel browser / le specifiche html - poiché al momento è solo metà della risposta.

Ecco un problema che ho come utente: non ho idea se la mia password verrà cancellata dall'altra parte quando verrà archiviata nel database. Le linee tra me e il server potrebbero essere crittografate, ma non ho idea di cosa accada alla mia password una volta raggiunta la destinazione, forse memorizzata come testo normale. Il tipo di amministratore del database potrebbe finire per vendere il database e prima che tu lo sappia, tutto il mondo conosce la tua password.

La maggior parte degli utenti riutilizza le password. Persone non tecniche perché non conoscono meglio. Tecnici perché una volta arrivata alla quindicesima password o giù di lì la maggior parte delle persone non ha la possibilità di ricordarli a meno che non li scrivano (cosa che tutti sappiamo è anche una cattiva idea).

Se Chrome o IE o qualsiasi altra cosa stia usando, potrebbe dirmi che una casella di password sarà immediatamente hash lato client utilizzando un server generato salt e in modo efficace sandbox la password stessa - quindi saprei che come utente potrei riutilizzare una password con meno rischi. Vorrei comunque che i canali crittografati non desiderassero che succedesse gronda durante la trasmissione.

L'utente deve sapere che la sua password non è nemmeno disponibile per essere inviata al server - solo l'hash. Al momento, anche usando la soluzione di X4U, non hanno modo di saperlo perché non si sa se quella tecnologia è in uso.

— Chris Nevill
fonte

1

è integrato nel browser cercare l'autenticazione digest e vedrai i passaggi avanti e indietro adottati in http per ottenere una password con hash, con informazioni aggiuntive e verificati sul server.

— gbjbaanb,

-1

Penso che sia un buon metodo da usare quando si costruisce qualcosa come un framework, un CMS, un software per forum, ecc., Dove non si controllano i server su cui potrebbe essere installato. Cioè, SÌ, dovresti sempre raccomandare l'uso di SSL per accessi e attività di accesso, ma alcuni siti che usano il tuo framework / cms non lo avranno, quindi potrebbero comunque trarne vantaggio.

Come altri hanno sottolineato, il vantaggio qui NON è che un attacco MITM non potrebbe consentire a qualcun altro di accedere a questo particolare sito come te, ma piuttosto che quell'attaccante non sarebbe quindi in grado di utilizzare la stessa combinazione nome utente / password per accedi probabilmente a dozzine di altri siti su cui potresti avere account.

Tale schema dovrebbe essere salato con un salt casuale o con una combinazione di sali specifici del sito e specifici del nome utente, in modo che qualcuno che ottiene la password non possa utilizzarla per lo stesso nome utente su altri siti (anche i siti che utilizzano lo stesso schema di hashing ), né contro altri utenti del sito che potrebbero avere la stessa password.

Altri hanno suggerito che gli utenti dovrebbero creare password univoche per ogni singolo sito che usano o utilizzare i gestori di password. Mentre questo è un buon consiglio in teoria, sappiamo tutti che è una follia fare affidamento nel mondo reale. La percentuale di utenti che fa una di queste cose è piccola e dubito che cambierà presto.

Quindi un hash di password javascript è il minimo che uno sviluppatore di framework / cms può fare per limitare il danno di qualcuno che intercetta le password in transito (che è facile su reti wifi in questi giorni) se sia il proprietario del sito che gli utenti finali sono negligenti sulla sicurezza (che probabilmente sono).

— matthewv789
fonte