Dichiarazione di non responsabilità: sono l'autore, il creatore, il proprietario e il manutentore di Have I Been Pwned e il servizio Pwned Passwords collegato.
Permettetemi di 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 in caso di violazione dei dati. Questo rimane il caso d'uso principale per il servizio oggi e ci sono quasi 5B di record per aiutare le persone a farlo.
Ho aggiunto le password pwned nell'agosto dello scorso anno dopo che il NIST ha rilasciato una serie di consigli su come rafforzare i modelli di autenticazione. Parte di questo consiglio include il seguente :
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to: Passwords obtained from previous breach corpuses.
Questo è ciò che gli indirizzi delle password pwned: NIST ha consigliato "cosa" si dovrebbe fare ma non ha fornito le password stesse. Il mio servizio affronta la parte "come" di esso.
Ora, praticamente, quanta differenza fa? È davvero come dici tu, è proprio come una situazione chiave su un milione di porte? Innanzitutto, anche se era , l'esempio IRL si interrompe perché non c'è modo che qualche persona anonima dall'altra parte del mondo possa provare la tua chiave della porta principale su milioni di porta in un modo rapido, anonimo. In secondo luogo, la distribuzione delle password non è in alcun modo lineare; le persone scelgono sempre le stesse stronzate e questo pone quelle password a rischi molto più alti di quelli che raramente vediamo. E infine, il riempimento delle credenziali è dilagante ed è un problema molto serio per le organizzazioni con servizi online. Ascolto continuamente dalle aziende le sfide che stanno affrontando con gli aggressori che tentano di accedere agli account delle persone con credenziali legittime . Non solo è difficile da fermare, ma potrebbe anche rendere la società responsabile - questo è comparso proprio la scorsa settimana: "Il messaggio della FTC è strong e chiaro: se i dati dei clienti sono stati messi a rischio da riempimento di credenziali , quindi essere la vittima corporativa innocente non è una difesa per un caso di applicazione" link
Avere visto una password in una violazione dei dati prima è solo un indicatore di rischio ed è uno che ogni organizzazione che utilizza i dati può decidere come gestire. Potrebbero chiedere agli utenti di sceglierne un altro se è stato visto molte volte prima (c'è un conto accanto a ognuno di essi), segnalare il rischio a loro o anche solo tacere 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 di k-Anonimia (liberamente disponibile) tramite API che è molto importante per proteggere l'identità della password di origine o semplicemente scaricare l'intero set di hash (anche liberamente disponibile) ed elaborarli localmente. Nessun termine di licenza, nessun requisito per l'attribuzione, basta andare e fare cose buone con esso:)