La lista de credential stuffing de Naz.API

Artículo original ↗ Discusión en Hacker News ↗

La noticia de que el conjunto de datos de credential stuffing de Naz.API se ha añadido a Have I Been Pwned ha dejado a muchos usuarios inseguros sobre qué pueden hacer, en la práctica, ya que la filtración suele exponer pares correo–contraseña sin indicar claramente qué servicios se vieron comprometidos. Los comentaristas sopesan las ventajas y desventajas de comprobar contraseñas mediante la API de k-anonimato de HIBP o sitios de búsqueda de terceros, rotar credenciales masivamente y confiar en gestores de contraseñas y passkeys, al tiempo que cuestionan la responsabilidad de los proveedores, posibles orígenes relacionados con malware de los datos y los límites de los modelos de autenticación actuales. En conjunto, el incidente pone de relieve lo extendidas que se han vuelto las filtraciones de credenciales y lo difícil que sigue siendo para las personas evaluar su exposición real.

Accionabilidad y confusión de los usuarios

  • Muchos comentaristas informan de que su correo electrónico está en Naz.API, pero no pueden ver qué sitio o qué contraseña estuvo involucrada, lo que hace que la alerta se sienta “sin acción posible”.
  • Las personas con cientos de inicios de sesión dicen que rotarlo todo no es realista; planean priorizar las cuentas de alto valor y las que siguen en uso.

Deseo de conocer la fuente de la filtración

  • Hay una fuerte demanda de saber con qué servicio o dominio estaba asociada cada credencial filtrada, tanto por razones prácticas (qué contraseña cambiar) como legales (por ejemplo, la rendición de cuentas bajo el RGPD).
  • Contraargumento: exponer contraseñas por correo electrónico o incluso demasiado contexto podría permitir a atacantes buscar contraseñas para correos arbitrarios.
  • Algunos sugieren que los correos de notificación al menos podrían incluir el nombre de la filtración/fuente cuando esté disponible, sin exponer contraseñas.

Naturaleza del conjunto de datos de Naz.API (¿Seagate? ¿Malware? ¿Agregador?)

  • Un hilo vincula Naz.API con vulnerabilidades del software NAS/API de Seagate; otros en la filtración dicen que nunca usaron productos de Seagate, así que esta explicación parece incompleta.
  • La publicación del blog y varios comentarios dicen que gran parte de los datos proviene de “stealer logs” (malware que exfiltra credenciales guardadas) y de colecciones de filtraciones previas (por ejemplo, “Polish Credentials”).
  • En conjunto, el alcance no está claro: probablemente una mezcla de datos antiguos y nuevos, registros de malware y múltiples filtraciones, en lugar de un único incidente ordenado.

Comprobación de contraseñas comprometidas

  • La gente habla de usar el servicio Pwned Passwords de HaveIBeenPwned, incluyendo:
    • API de k-anonimato en línea (hash local, enviar los primeros 5 caracteres).
    • Volcados completos de hash (≈37 GB) y herramientas/cachés locales para consultar sin conexión.
  • Los principales gestores de contraseñas integran estas comprobaciones; algunos usuarios señalan retrasos antes de que aparezcan nuevos datos.
  • Se menciona el sitio de búsqueda alternativo “0t” como expositor de detalles de Naz.API, pero incluye muchas filtraciones y su operador desalienta el scraping.

Gestión y rotación de contraseñas

  • Algunos rotan contraseñas antiguas con un calendario; otros sostienen que la rotación aporta poco si cada contraseña ya es única y fuerte.
  • Varios recomiendan gestores de contraseñas (Bitwarden, 1Password, KeePass + almacenamiento en la nube) junto con 2FA; otros mencionan borrar cuentas no usadas como parte de la limpieza.

Alias de correo y direcciones “canary”

  • Los comentaristas usan dominios personalizados o servicios de reenvío para dar a cada sitio un correo único, usando apariciones en filtraciones como “canarios” para identificar qué organización filtró datos.
  • Compromiso: esto puede complicar los servicios centralizados de alerta de filtraciones que solo vigilan un pequeño conjunto de direcciones de correo.

Alternativas de autenticación y temas generales de seguridad

  • Crece el apoyo a passkeys/llaves FIDO como más resistentes al phishing que las contraseñas.
  • Debate sobre la practicidad para “personas normales” (pérdida de la llave, copias de seguridad, recuperación) frente a una mejor seguridad.
  • Se habla de Wi‑Fi público: se considera que HTTPS es en su mayoría suficiente, pero siguen siendo una preocupación las aplicaciones mal escritas que debilitan TLS.