L'utente registra l'account su un'app Web. Le password sono salate e hash. Ma è sicuro verificare la password con l'HIBP API delle password pwned , prima di salarla e eseguirne l'hashing? Ovviamente l'app utilizza TLS.
Quindi, se la password viene trovata in caso di violazione, non consentire la registrazione di un account. Se la password non viene trovata in violazione, salvarla e memorizzarla in un database.
Lo stesso varrebbe se cambiando la password.
Sono stato pwned? consente a chiunque di scaricare il database completo per eseguire i controlli localmente.
Se questa non è un'opzione, l'utilizzo dell'API è sicuro, poiché utilizza k-anonimity che ti consente di eseguire il controllo senza trasmettere l'intera password / hash.
Se l'operatore dell'API di Pwned Passwords è malevolo (o il servizio è violato da una persona malintenzionata, o qualcuno intercetta la tua comunicazione) può mentire su certe password (restituire solo un sottoinsieme di password che conosce per quell'hash), registra da dove proviene la richiesta, identifica il sito web che appartiene a quell'ID, identifica l'account (in base al tempo di creazione, ad esempio) e testalo con le password su cui ha mentito, per una discreta possibilità di compromettere l'account.
Questo è uno scenario abbastanza improbabile (il proprietario dell'API è un professionista della sicurezza rispettabile, l'elenco degli hash noti è pubblico e fare questo tipo di attacco senza essere rilevato sarebbe difficile), quindi dipende da come avverso sei. Se si esegue un forum di discussione, l'utilizzo dell'API è sicuramente una buona idea. Se gestisci una e-bank, forse non così tanto.
Scaricare il database e fare i controlli localmente è certamente più sicuro, ma non un compito banale, date le dimensioni.
A partire dalla pubblicazione di questa risposta, la domanda chiede se è sicuro inviare una password "prima di salarlo e cancellarlo", il che significa in testo semplice. Devi mai inviare una password in testo normale a una terza parte (la seconda parte potrebbe essere OK se stai effettuando l'accesso). Anche l'hashing della password non è sufficiente, in quanto una Rainbow Table può essere utilizzata per cercare la password. Questo è il motivo per cui ho visto qualcuno (hashing e) inviare ogni singola password in un database KeePass a HIBP , Li ho immediatamente chiamati su di esso.
Come hanno sottolineato altre risposte, esiste una nuova versione di HIBP che include k- anonimato (vedi quel link e le altre risposte per maggiori informazioni). Tuttavia, questo sta ancora divulgando alcune informazioni sulle password (a HIBP e qualsiasi potenziale MITM attacker. Divulgare alcune informazioni non è affatto così male come perdere l'intera password, ma è comunque qualcosa di cui dovresti preoccuparti. Quello che vuoi veramente è che le tue password siano sicuro, non anonimo .
In definitiva, se si desidera assicurarsi che nessuna informazione relativa alle password sia trapelata nel processo di verifica, è necessario scaricare l'intera base dati di password pwned e hash e controlla la tua password localmente (in questo caso, sul server perché nessuno vuole scaricare l'intero DB solo per creare un account). Basta non memorizzare la password o l'hash che si sta confrontando con il DB, ma solo memorizzare l'hash salato nel proprio database delle password.
Solo per aggiungere qualcosa alle risposte precedenti Non riesco a pensare ad altri seri problemi di sicurezza nel controllare le password contro il sito, ma dal punto di vista dell'esperienza utente potrebbe essere meglio controllare l'e-mail e la password insieme e poi notificare il utente se entrambi restituiscono true. Inoltre non impedirei loro di usarlo se restituisce true. Ho appena provato 30 password casuali appena generate e 4 di esse sono tornate vere sul sito. Non sono sicuro al 100% di come lo implementeresti usando l'API, ma probabilmente sarebbe quello che mi piacerebbe fare.
Leggi altre domande sui tag passwords web-application hash salt have-i-been-pwned