Un utente non può mai memorizzare una password se è stato usato un hash username / email?

Se il protocollo che usi è vulnerabile agli attacchi Man-in-the-Middle , poi perdi comunque, indipendentemente da quanta procedura si applica: l'attaccante MitM può solo aspettare che venga eseguita l'autenticazione, quindi dirottare la connessione in quel punto. Devo dire, però, che SSL è NOT vulnerabile a MitM, a condizione che nessuno faccia qualcosa di stupido (ad esempio, guardando un grande avvertimento rosso dal browser che dice "questo server usa un certificato non valido "e facendo clic su" shuddup voglio collegarmi comunque " è " qualcosa di stupido ").

Quindi stiamo parlando di un utente che ha fatto qualcosa di abbastanza grave da violare SSL; e lo stesso utente anche ha riutilizzato la stessa password su diversi siti. Sfortunatamente, ci sono molti utenti che fanno queste cose. La tua proposta presenta due problemi principali:

• L'archiviazione della password deve utilizzare hashing della password , con sali e lentezza . Viene applicato un numero elevato di iterazioni, in modo che un utente malintenzionato in grado di scaricare il database del server soffra ancora molto quando tenta di decifrare le password. Ma nel tuo caso, questo hashing DEVE necessariamente verificarsi sul lato client, in Javascript. Javascript è lontano ( molto lontano) dall'avere abbastanza muscoli per farlo. Ciò implicherebbe la divisione del numero di iterazioni di almeno 10 (probabilmente di più) in modo che il tempo di accesso rimanga tollerabile, dividendosi quindi per almeno 10 di sicurezza contro un attacco di dizionario offline.

• JavaScript . Il codice che esegue l'hashing è stato appena servito dal server stesso, tramite la connessione che si supponeva fosse sotto attacco MitM. Un tale aggressore può modificare questo Javascript a proprio piacimento. Vale a dire, può aggiungere un po 'di Javascript in più che anche invia il login e la password (come inseriti dall'utente) al suo malvagio server.

Il secondo punto rende discutibile la discussione: se un utente malintenzionato può eseguire un MitM riuscito, allora può prendere la password dal sorgente, cioè il campo di immissione nella pagina Web, e nessuna quantità di Javascript può cambiare nulla a tale scopo.

Sì. Per Tom Leek , questo non può essere fatto lato server. Ci sono estensioni del browser che hash password (utilizzando il dominio come parte della password non modificata) prima di inviarlo a un server. Questo non fornisce protezione contro tutti gli attacchi MiTM, sebbene protegga da alcuni tipi di attacchi.

Ci sono alcuni vantaggi a questo approccio:
1. Gli utenti possono utilizzare la stessa password su ogni sito, senza le vulnerabilità associate.
2. I siti di phishing hanno la password "errata".
3. La password hash è in genere crittograficamente più potente della password originale.

E alcuni aspetti negativi:
1. L'utente deve fidarsi dell'estensione.
2. Se l'estensione utilizza hashing interrotto, la situazione dell'utente non è sostanzialmente migliore rispetto a quella in cui l'utente ha utilizzato la stessa password su ogni sito.
3. La password generata potrebbe non essere accettata su alcuni siti (ad esempio, considerare due siti, uno che non accetta password contiene simboli e un altro che richiede simboli). Rendere possibile questa configurazione è possibile, ma rende il programma più difficile da utilizzare.
4. Questa protezione potrebbe non riuscire se l'utente digita la password direttamente nel sito, poiché il sito potrebbe essere in ascolto tramite javascript. Strumenti di hashing ben progettati attenueranno tali attacchi utilizzando una chiave privata univoca come parte dell'hash.
5. Supponendo che l'utente abbia una chiave privata, l'accesso a un sito fallirà se l'utente si trova su un computer diverso o il suo computer corrente in qualche modo perde la chiave (a causa di un aggiornamento o simili). Se questa chiave privata è basata su password, allora la soluzione basata su hash perché inutile; a quel punto è un gestore di password glorificato.