Privacy e Dati

k-Anonymity su HIBP: come controllare una password senza inviarla intera

6 min di lettura
Laptop su scrivania scura: check password k-anonymity con prefisso 5BAA6 evidenziato in arancione e hash completo che resta sul dispositivo
Windows macOS Linux Android iOS
Immagine generata: Alex Lunalbi · Gemini · ai riparo

Scopri come funziona k-Anonymity su Have I Been Pwned. Una guida pratica per verificare se la tua password è stata violata senza doverla inviare in chiaro.

Nell’approfondimento su come sapere se email e password sono compromesse (lettura opzionale) ho spiegato che inserire l’email su Have I Been Pwned (HIBP) è, nella pratica, un controllo ragionevole: l’indirizzo è un dato di contatto, non un segreto.

Con il form Passwords la posta in gioco è diversa. Digitare una password che usi ancora in una casella web, per quanto autorevole sia il sito, va contro l’igiene digitale di base.

Eppure HIBP offre quel controllo in modo (quasi del tutto) sicuro grazie a un modello chiamato k-Anonymity. Qui ti mostro cosa succede davvero dietro le quinte: cosa lascia il tuo dispositivo, cosa vede il server e quando ha senso usare lo strumento — o lasciarlo stare.

Il problema: verificare un segreto senza svelarlo

Se un servizio ha centinaia di milioni di password violate e vuoi sapere se la tua è tra quelle, la soluzione ingenua (e sbagliata) è inviargli la password e fargli fare la ricerca.

Anche con HTTPS, staresti consegnando il segreto in chiaro al server di destinazione. Dovresti fidarti che non lo salvi, che non venga compromesso in quel momento e che non associ la richiesta al tuo IP in log utili a un attaccante.

Per questo Troy Hunt, con Cloudflare, ha reso pubblica l’API Pwned Passwords basata su k-Anonymity. L’idea: nascondersi nella folla. Invece di chiedere «hai questa password?», il client chiede: «dammi tutti gli hash violati che iniziano così».

Come funziona k-Anonymity in pratica

Esempio didattico con una password fittizia che non dovresti riusare da nessuna parte: GattoRosso2026!.

1. Hash locale (SHA-1)

Il JavaScript della pagina (o il tuo script locale) calcola subito l’hash SHA-1 della password. Un hash è una stringa a lunghezza fissa: da lì non “torni indietro” alla password come con una cifratura.

Per GattoRosso2026! l’hash SHA-1 completo è:

ED946C863F7601B8110F047BE06F5E764D42BB5A

(Puoi verificarlo tu: in Python, hashlib.sha1(b"GattoRosso2026!").hexdigest().upper().)

2. Prefisso e suffisso

Il client spezza l’hash in due:

  • Prefisso: i primi 5 caratteri → ED946
  • Suffisso: i restanti 35 → C863F7601B8110F047BE06F5E764D42BB5A

3. Richiesta al server (solo il prefisso)

Verso l’API di HIBP parte solo il prefisso (ED946). La password in chiaro non lascia il dispositivo; nemmeno l’hash completo.

In rete la chiamata tipica è una range request verso api.pwnedpasswords.com con quel prefisso nell’URL. Su Windows, macOS o Linux puoi aprirlo tu nel browser (DevTools → Rete / Network) mentre usi il form ufficiale: cerchi una richiesta il cui path contiene i 5 caratteri, non la password.

4. Risposta di HIBP

Il server elenca gli hash del database che iniziano con quel prefisso (spesso centinaia). Restituisce solo i suffissi, con il conteggio di quante volte compaiono nei breach.

5. Confronto locale

Il client scorre l’elenco in locale e cerca il tuo suffisso:

  • se c’è → la password risulta nei breach noti (“pwned”);
  • se non c’è → non risulta in quegli archivi.

Qui sta la k-Anonymity: il server sa solo che stai cercando qualcosa il cui hash inizia per ED946. Accanto alla tua ci sono altre k password possibili con lo stesso prefisso. Per il server è poco realistico capire quale suffisso stai confrontando sul tuo PC.

La regola d’oro: quando usarla e quando saltarla

Il protocollo è solido; restano ambiente e abitudini.

  1. Password vecchie, sospette o didattiche — ok usare HIBP (o l’API) per password abbandonate, esempi da mostrare a un parente (Napoli1990 e simili), o per capire il meccanismo.
  2. Password attive e critiche — evita di incollare nel browser la master password del password manager, i codici del conto o la password principale della posta / lavoro.

🚨 Avviso critico — Fiducia nel dominio
k-Anonymity protegge il transito verso l’API ufficiale. Non ti protegge da un sito clone (phishing) che imita HIBP: lì il JavaScript malevolo può registrare la tastiera prima dell’hash. Per i segreti ancora in uso, la scelta più pulita è spesso non digitarli in form web opzionali e cambiarli se hai un dubbio concreto.

Se temi che una password vitale sia compromessa, il tempo per “provare” HIBP è spesso meglio speso a sostituirla con una stringa lunga, unica e generata da un password manager (lettura opzionale) o dal generatore offline.

Errori e fraintendimenti comuni

  • Non sei “invisibile” sul tuo PC. Keylogger, estensione malevola o malware catturano la password al digito, a prescindere dall’hash.
  • k-Anonymity non rende forte una password debole. Protegge la query, non trasforma estate2020 in una buona credenziale.
  • “Good news” ≠ password sicura. Significa solo: non risulta nei breach noti a HIBP. Può restare corta, riusata o indovinabile.

Domande Frequenti (FAQ)

HIBP vede la mia password intera?

No, sul form ufficiale del sito: il browser calcola l’hash in locale e invia solo i primi 5 caratteri. La password in chiaro non dovrebbe partire verso il server.

Perché HIBP usa SHA-1 e non SHA-256?

SHA-1 è debole come algoritmo di protezione per archiviare password o firmare documenti. Qui serve soprattutto come chiave di ricerca (lookup) nell’API a range. L’obiettivo non è “nascondere per sempre” la password sul server, ma consentire il confronto a frammenti con poco traffico. Nel modello di minaccia di Pwned Passwords questo uso è ancora accettato dal servizio.

Posso controllare così la password di Gmail?

Matematicamente il protocollo ufficiale è pensato per non rivelare la password al server. Come igiene digitale, però, sconsiglio di incollare credenziali altamente critiche in campi web opzionali. Se dubiti della password di Gmail (o della posta principale), cambiala e attiva 2FA / passkey: è più utile di un check curioso.

Se esce “pwned” ma non ricordo dove l’ho usata?

Non serve ricordare il breach esatto. Se è “pwned”, quella stringa circola in archivi noti: cambiala su ogni account in cui potresti averla riusata.

k-Anonymity mi protegge da un sito HIBP falso?

No. Il protocollo vale nel dialogo con l’API (o il form) ufficiale. Su un clone, lo script della pagina può rubare la password in chiaro appena la digiti.

È più sicuro usare l’API con uno script Python locale?

Può ridurne i rischi legati al browser (estensioni, tab sbagliata, clone). Lo script calcola SHA-1 in locale, chiede solo il prefisso a api.pwnedpasswords.com e confronta i suffissi sul tuo PC — stessa logica di questa guida, senza form web. Restano validi malware sul sistema e la regola di non testare segreti critici “per curiosità”.

Conclusioni

k-Anonymity su Have I Been Pwned è un esempio concreto di come un protocollo possa rispondere a una domanda scomoda (questa password è nei breach?) senza consegnare il segreto intero al server. Capire hash, prefisso, suffisso e confronto locale ti permette di usare lo strumento con giudizio, non per fede cieca né per panico.

La tecnologia non sostituisce le abitudini: password lunghe e uniche, un gestore affidabile e — dopo un breach — cambio credenziali e 2FA restano la difesa che conta ogni giorno.

Alex Lunalbi

Alex Lunalbi

Security & privacy

Dona su PayPal

Scrivo di sicurezza digitale pratica e codice IA. Su ai riparo ogni procedura è verificata su macchine reali.

Tag
  • privacy,
  • password,
  • data breach,
  • sicurezza