The Naz.API Credential Stuffing List

Original Article ↗ Hacker News Discussion ↗

News of the Naz.API credential-stuffing dataset being added to Have I Been Pwned has left many users uncertain about what, if anything, they can practically do, since the breach often exposes email–password pairs without clearly indicating which services were compromised. Commenters weigh trade-offs between checking passwords via HIBP’s k‑anonymity API or third-party search sites, mass-rotating credentials, and relying on password managers and passkeys, while also questioning vendor responsibility, possible malware origins of the data, and the limits of current authentication models. Overall, the incident highlights how pervasive credential leaks have become and how hard it remains for individuals to assess their real-world exposure.

Actionability and User Confusion

  • Many commenters report their email is in Naz.API but they cannot see which site or which password was involved, making the alert feel “inactionable.”
  • People with hundreds of logins say rotating everything isn’t realistic; they plan to prioritize high‑value accounts and ones still in use.

Desire to Know Breach Source

  • Strong demand to know which service or domain each leaked credential was associated with, both for practical reasons (which password to change) and legal ones (e.g., GDPR accountability).
  • Counter‑argument: exposing per‑email passwords or even too much context could enable attackers to look up passwords for arbitrary emails.
  • Some suggest notification emails could at least include the breach/source name when available, without exposing passwords.

Naz.API Dataset Nature (Seagate? Malware? Aggregator?)

  • One thread links Naz.API to Seagate NAS software/NAS API vulnerabilities; others in the breach say they never used Seagate products, so this explanation seems incomplete.
  • The blog post and several comments say much of the data comes from “stealer logs” (malware exfiltrating saved credentials) and from prior breach collections (e.g., “Polish Credentials”).
  • Overall scope is unclear: likely a mix of old and new data, malware logs, and multiple breaches rather than one tidy incident.

Checking Compromised Passwords

  • People discuss using HaveIBeenPwned’s Pwned Passwords service, including:
    • Online k‑anonymity API (hash locally, send first 5 chars).
    • Full hash dumps (≈37 GB) and local tools / caches to query offline.
  • Major password managers integrate these checks; some users note delays before new data shows up.
  • Alternative search site “0t” is mentioned as exposing Naz.API details, but includes many leaks and its operator discourages scraping.

Password Management & Rotation

  • Some rotate old passwords on a schedule; others argue rotation adds little if each password is already unique and strong.
  • Several recommend password managers (Bitwarden, 1Password, KeePass + cloud storage) plus 2FA; others mention deleting unused accounts as part of cleanup.

Email Aliases and “Canary” Addresses

  • Commenters use custom domains or forwarding services to give each site a unique email, using appearances in breaches as “canaries” to identify which organization leaked data.
  • Tradeoff: this can complicate centralized breach‑alert services that only watch a small set of email addresses.

Authentication Alternatives and General Security Topics

  • Growing support for passkeys/FIDO keys as more phishing‑resistant than passwords.
  • Debate over practicality for “regular people” (key loss, backups, recovery) versus improved security.
  • Public Wi‑Fi is discussed: HTTPS is seen as mostly adequate, but poorly written apps that weaken TLS remain a concern.