Disclaimer: sono l'autore, il creatore, il proprietario e il manutentore di Have I Been Pwned e del servizio Pwned Passwords collegato.
Vorrei chiarire tutti i punti sollevati qui:
Lo scopo originale di HIBP era consentire alle persone di scoprire dove il loro indirizzo email era stato esposto a violazioni dei dati. Questo rimane il caso d'uso principale per il servizio oggi e ci sono quasi 5 miliardi di record per aiutare le persone a farlo.
Ho aggiunto Pwned Passwords nell'agosto dello scorso anno dopo che il NIST ha rilasciato una serie di consigli su come rafforzare l'autenticazione Modelli. Parte di quel consiglio includeva quanto segue:
Durante l'elaborazione delle richieste per stabilire e modificare i segreti memorizzati, i verificatori DEVONO confrontare i potenziali segreti con un elenco che contiene valori noti per essere di uso comune, previsto o compromesso. Ad esempio, l'elenco POTREBBE includere, ma non è limitato a: Password ottenute da corpi di violazione precedenti.
Questo è ciò che Pwned Passwords indirizzi: NIST ha consigliato "cosa" dovresti fare ma non fornire le password stesse. Il mio servizio affronta la parte "come" di esso.
Ora, praticamente, quanta differenza fa? È davvero come dici tu che è proprio come una situazione chiave su un milione di porte d'ingresso? Bene, in primo luogo, anche se lo fosse , l'esempio IRL fallisce perché non è possibile che una persona anonima dall'altra parte del mondo possa provare la tua chiave della porta principale su milioni di porta in modo rapido e anonimo. In secondo luogo, la distribuzione delle password non è in alcun modo lineare; le persone scelgono le stesse schifezze più e più volte e questo mette quelle password a rischi molto più alti di quelli che vediamo raramente. E infine, il credential stuffing è dilagante ed è un problema davvero serio per le organizzazioni con servizi online. Sento continuamente dalle aziende le sfide che devono affrontare gli aggressori che tentano di accedere agli account delle persone con credenziali legittime . Non solo è così difficile da fermare, ma potrebbe anche rendere l'azienda responsabile - questo è saltato fuori solo la scorsa settimana: "Il messaggio della FTC è forte e chiaro: se i dati dei clienti sono stati messi a rischio dal riempimento delle credenziali quindi essere la vittima aziendale innocente non è una difesa contro un caso di esecuzione " https://biglawbusiness.com/cybersecurity-enforcers-wake-up-to-unauthorized-computer-access-via-credential-stuffing/
L'aver visto una password in una violazione dei dati in passato è solo un indicatore di rischio ed è uno che ogni organizzazione che utilizza i dati può decidere come gestirla. Potrebbero chiedere agli utenti di sceglierne un altro se è stato visto molte volte in precedenza (c'è un conteggio accanto a ciascuno), segnalare loro il rischio o anche solo contrassegnare silenziosamente l'account. Questa è una difesa insieme a MFA, anti-automazione e altre euristiche basate sul comportamento. È solo una parte della soluzione.
E per inciso, le persone possono utilizzare il modello k-Anonymity (disponibile gratuitamente) tramite API che contribuisce notevolmente a proteggere l'identità della password di origine o semplicemente scaricare l'intero set di hash (anch'essi disponibili gratuitamente) ed elaborarli localmente. Nessun termine di licenza, nessun requisito di attribuzione, basta andare e fare cose buone con esso :)