A Lista de Credential Stuffing do Naz.API
A notícia de que o conjunto de dados de credential stuffing Naz.API foi adicionado ao Have I Been Pwned deixou muitos usuários sem saber o que, se é que algo, podem fazer na prática, já que a violação frequentemente expõe pares email–senha sem indicar claramente quais serviços foram comprometidos. Os comentaristas ponderam os trade-offs entre verificar senhas via a API de k-anonymity do HIBP ou sites de busca de terceiros, rotacionar credenciais em massa e confiar em gerenciadores de senhas e passkeys, ao mesmo tempo em que questionam a responsabilidade dos fornecedores, possíveis origens em malware dos dados e os limites dos modelos de autenticação atuais. No geral, o incidente destaca como vazamentos de credenciais se tornaram onipresentes e como ainda é difícil para indivíduos avaliar sua exposição no mundo real.
Ação Prática e Confusão do Usuário
- Muitos comentaristas relatam que o seu email está no Naz.API, mas não conseguem ver qual site ou qual senha estava envolvida, o que faz o alerta parecer “sem ação possível”.
- Pessoas com centenas de logins dizem que rotacionar tudo não é realista; elas planejam priorizar contas de alto valor e as que ainda estão em uso.
Desejo de Saber a Origem da Violação
- Há uma forte demanda para saber a qual serviço ou domínio cada credencial vazada estava associada, tanto por razões práticas (qual senha mudar) quanto legais (por exemplo, responsabilidade sob o GDPR).
- Contra-argumento: expor senhas por email ou até contexto demais poderia permitir que atacantes consultem senhas de emails arbitrários.
- Alguns sugerem que emails de notificação poderiam ao menos incluir o nome da violação/origem quando उपलब्धível, sem expor senhas.
Natureza do Conjunto de Dados Naz.API (Seagate? Malware? Agregador?)
- Um fio liga o Naz.API a vulnerabilidades no software NAS da Seagate/NAS API; outros na violação dizem nunca ter usado produtos da Seagate, então essa explicação parece incompleta.
- O post do blog e vários comentários dizem que grande parte dos dados vem de “stealer logs” (malware exfiltrando credenciais salvas) e de coleções de violações anteriores (por exemplo, “Polish Credentials”).
- O escopo geral não está claro: provavelmente uma mistura de dados antigos e novos, logs de malware e múltiplas violações, em vez de um único incidente organizado.
Verificando Senhas Comprometidas
- As pessoas discutem usar o serviço Pwned Passwords do HaveIBeenPwned, incluindo:
- API online de k-anonymity (hash localmente, enviar os primeiros 5 caracteres).
- Dumps completos de hash (≈37 GB) e ferramentas locais / caches para consultar offline.
- Principais gerenciadores de senhas integram essas verificações; alguns usuários observam atrasos até que novos dados apareçam.
- O site de busca alternativo “0t” é mencionado como expondo detalhes do Naz.API, mas inclui muitas vazamentos e seu operador desencoraja scraping.
Gerenciamento de Senhas e Rotação
- Alguns rotacionam senhas antigas em um cronograma; outros argumentam que a rotação agrega pouco se cada senha já for única e forte.
- Vários recomendam gerenciadores de senhas (Bitwarden, 1Password, KeePass + armazenamento em nuvem) mais 2FA; outros mencionam apagar contas não usadas como parte da limpeza.
Aliases de Email e Endereços “Canary”
- Os comentaristas usam domínios personalizados ou serviços de encaminhamento para dar a cada site um email único, usando aparições em vazamentos como “canaries” para identificar qual organização vazou dados.
- Trade-off: isso pode complicar serviços centralizados de alerta de violação que monitoram apenas um pequeno conjunto de endereços de email.
Alternativas de Autenticação e Tópicos Gerais de Segurança
- Cresce o apoio a passkeys/chaves FIDO como mais resistentes a phishing do que senhas.
- Debate sobre a praticidade para “pessoas comuns” (perda da chave, backups, recuperação) versus segurança aprimorada.
- Wi‑Fi público é discutido: HTTPS é visto como em grande parte adequado, mas aplicativos mal escritos que enfraquecem o TLS continuam sendo uma preocupação.