Perché quasi nessuna pagina Web ha hash password nel client prima di inviarle (e le hashing di nuovo sul server), come per "proteggere" contro il riutilizzo della password?

Perché non viene usato? Perché è un sacco di lavoro extra per guadagnare 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 della password, le password del dizionario, ecc.)

In theory this doesn't give any extra security, but in practice this can be used to protect against "rogue sites" that don't hash your password in the server.

In che modo esattamente ti protegge? Sembra che tutto quello che vuoi fare è hash la password hash che è un po 'inutile. Perché la password con hash diventerebbe la password.

There are many sites on the Internet that require login information, and the only way to protect against password reusing is the "promise" that the passwords are hashed on the server, which is not always true.

Che dire di non usare la stessa password per più di un sito. La ragione per cui i siti Web hanno cancellato la password in teoria è impedire l'accesso al tuo account se sono compromessi. Utilizzare la stessa password per più siti Web è semplicemente stupido.

Se hai usato javascript, tutto quello che "l'hacker" dovrebbe fare è usare lo stesso metodo sulle password hashed-hash. Una volta che hai le informazioni hash, il tempo necessario per calcolare lo stesso hash della password nel database è un fattore che impedisce l'accesso a un account.

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

Secure 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 esso.

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

La soluzione è più semplice di così. Certificati client Creo un certificato client sulla mia macchina. Quando mi registro con 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 ha hackerato il database, tutto quello che avranno è la chiave pubblica del mio certificato client (che dovrebbe essere salato e crittografato dal server per un ulteriore livello di sicurezza).

Il certificato del cliente può essere memorizzato su una smart card (e caricato su un deposito online sicuro utilizzando una password principale).

La bellezza di tutto questo è che rimuove il concetto di phishing via ... non stai mai inserendo una password in un sito web, stai solo stringendo le mani su 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 di simile in Windows con Cardspace e successivamente lo ha presentato come standard aperto. OAuth è in qualche modo simile ma si basa su un "partito emittente" intermedio. InfoCard, d'altra parte, potrebbero essere autoprodotte. Questa è la vera soluzione al problema della password ... rimuovendo completamente le password.

OAuth è un passo nella giusta direzione però.

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

il punto è non per proteggere l'accesso al server al quale 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 quello di proteggere la password dell'utente , che di solito è molto più preziosa dell'accesso al singolo accesso al sito poiché la maggior parte degli utenti riutilizzerà la propria password per più siti (non dovrebbero, ma la realtà è che lo facciano non dovrebbe essere sventolato)

ssl è ottimo per proteggere dagli attacchi di mitm, ma se un'applicazione di login è compromessa sul server, ssl non proteggerà i tuoi utenti. se qualcuno ha maliziosamente ottenuto l'accesso a un server Web, è probabile che sia in grado di intercettare le password in testo semplice perché nella maggior parte dei casi le password vengono solo sottoposte a hashing da uno script sul server. quindi l'utente malintenzionato può provare quelle password su altri siti (di solito più preziosi) utilizzando nomi utente simili.

la sicurezza è difesa in profondità e l'hashing lato client aggiunge semplicemente un altro livello. ricorda che proteggere l'accesso al tuo sito è importante, ma proteggere la segretezza delle password dei tuoi utenti è molto più importante a causa del riutilizzo della password su altri siti.

È sicuramente possibile, e in realtà non è necessario aspettare 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, lo ha cancellato, lo maneggia in modo tale da ottenere solo i caratteri "ammessi" nella password, e solo allora la password hash viene inviata sul filo.

Utilizzando il dominio del sito nel processo, ottieni quindi una password univoca per sito, anche se riutilizzi sempre la stessa password.

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

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

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

Ecco un problema che ho come utente - non ho idea se la mia password verrà sottoposta a hash all'altra estremità se conservata nel database. Le linee tra me e il server potrebbero essere crittografate, ma non ho idea di cosa succede alla mia password una volta raggiunta la destinazione - forse è memorizzata come testo normale. Il responsabile dell'amministrazione del database può finire per vendere il database e prima che tu lo sappia, il mondo intero conosce la tua password.

La maggior parte degli utenti riutilizza le password. Persone non tecniche perché non le conoscono meglio. Gente tecnica perché una volta raggiunta la quindicesima password o quasi tutte le persone non hanno la possibilità di ricordarle a meno che non le scrivano (che tutti sappiamo essere anche una cattiva idea).

Se Chrome o IE o qualunque cosa stavo usando, potrei dirmi che una casella di password sarà istantaneamente sottoposta a client hash con un server generato in modo salato ed efficacemente sandbox la password stessa - quindi vorrei sapere che come utente Potrei riutilizzare una password con meno rischi. Vorrei ancora i canali criptati e non voglio alcuna interruzione 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 utilizzando la soluzione di X4U, non hanno modo di sapere che questo è il caso perché non sai se tale tecnologia è in uso.

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

Come altri hanno sottolineato, il vantaggio qui NON è che un attacco MITM non possa permettere a qualcun altro di accedere a questo particolare sito come te, ma piuttosto che quell'attaccante non sarebbe quindi in grado di usare lo stesso nome utente / password combinata per accedere a dozzine di altri siti su cui potresti avere account.

Tale schema dovrebbe essere saltato con un salt casuale, o qualche combo di sali specifici del sito e specifici del nome utente, in modo che qualcuno che guadagna la password non possa usarlo per lo stesso nome utente su altri siti (anche i siti che usano il schema di hashing identico), né nei confronti di altri utenti del sito del sito che potrebbero avere la stessa password.

Altri hanno suggerito agli utenti di creare password univoche per ogni singolo sito che utilizzano 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 con le reti wifi in questi giorni) se sia il proprietario del sito che gli utenti finali sono negligenti in merito alla sicurezza (che probabilmente sono).