2 pontos por GN⁺ 2025-05-20 | 1 comentários | Compartilhar no WhatsApp
  • O serviço de verificação de vazamentos de dados Have I Been Pwned foi totalmente reformulado
  • Junto com o novo design, as principais funções das páginas web foram amplamente alteradas e melhoradas
  • A função de busca ficou mais intuitiva, e foram reforçadas as orientações sobre como verificar contas e entender diferentes casos de violação de dados
  • Foram adicionados vários novos recursos e melhorias, como painel do usuário, busca de domínio e documentação da API
  • O desempenho web e a segurança foram implementados sobre uma infraestrutura moderna de nuvem, oferecendo uma experiência rápida e segura aos usuários

Introdução e contexto

  • O Have I Been Pwned (doravante HIBP) 2.0 foi relançado de forma totalmente renovada após um longo período de desenvolvimento
  • O primeiro commit foi feito em fevereiro de 2023 e, após um soft launch em março de 2024 e o processo de open source, o site foi aberto com reconstrução completa e uma nova identidade de marca
  • Toda a estrutura e as funções do site foram reformuladas, e uma loja de merchandise também foi lançada junto com novos recursos

Função de busca

  • A busca principal na página inicial, recurso mais representativo do HIBP, foi melhorada com uma experiência mais intuitiva e uma apresentação mais leve, incluindo animação de confete
  • Para não tornar a experiência do usuário pesada, evitou-se um tom sombrio e negativo, com foco em fornecer informações práticas baseadas em fatos
  • As buscas por nome de usuário e número de telefone foram removidas do site (mas permanecem na API da forma anterior)
    • A busca por endereço de e-mail é mais adequada em termos de parsing, alertas e consistência do serviço
    • Números de telefone e nomes de usuário exigem mais esforço no processamento de dados e quase não são usados na prática, então foram excluídos para reduzir confusão

Página de casos de violação de dados

  • Cada incidente de breach (vazamento) agora conta com uma página detalhada dedicada
  • Com um layout mais intuitivo e visualmente melhor do que antes, a página apresenta orientações específicas e acionáveis sobre impacto e medidas de resposta
  • Estão previstas futuras adições em parceria com outras instituições (por exemplo, NCSC), como informações adaptadas por região
  • No futuro, serão adicionados detalhes como suporte a 2FA, passkeys e guias personalizados para usuários

Painel

  • Vários recursos existentes, como verificação de breaches sensíveis, gerenciamento de domínio e gerenciamento de assinatura, foram unificados em um painel integrado
  • O painel é acessado com base em verificação por e-mail, e futuramente também deverá receber novos métodos de autenticação, como passkeys
  • Isso cria espaço para evoluir para uma plataforma expansível, incluindo recursos futuros como alertas para contas familiares

Função de busca de domínio

  • A funcionalidade de verificação/busca de domínio foi totalmente redesenhada, com uma UI mais limpa e suporte a vários filtros, como visualizar apenas os vazamentos mais recentes
  • Com arquitetura completa de single-page app (SPA), os resultados de busca são entregues rapidamente em JSON via API
  • O processo de verificação de propriedade do domínio também foi simplificado
  • Métodos de autenticação além de e-mail deverão ser melhorados separadamente no futuro

API

  • Nesta atualização, não houve nenhuma mudança nem interrupção na própria API
  • A documentação da API está se preparando para adotar a ferramenta Scalar baseada em OpenAPI, mas por enquanto mantém a documentação atual com um novo estilo unificado
  • Futuramente, ela será migrada para uma documentação moderna baseada em Scalar

Merchandise e stickers

  • A loja oficial de produtos da marca HIBP foi aberta, com início das vendas de itens como camisetas (baseada em Teespring, sem margem)
  • Os stickers continuam disponíveis na loja da Sticker Mule, e a arte pode ser usada livremente por ser open source

Tecnologia e infraestrutura

  • O backend do site é baseado em Microsoft Azure, usando App Service, Functions, Hyperscale SQL, Storage e outros serviços
  • Os principais aplicativos web foram escritos em C# e .NET 9.0, com ASP.NET MVC (.NET Core)
  • O Cloudflare é amplamente usado para WAF, cache, Turnstile (anti-bot), armazenamento R2 e outros recursos importantes
  • No frontend, uma interface moderna foi construída com base em Bootstrap atualizado, SASS e TypeScript
  • Com contribuições de membros-chave como o desenvolvedor islandês Ingiber, foi alcançado um alto nível de acabamento e uma UI refinada
  • O tamanho das páginas e o número de requisições web foram reduzidos em cerca de 28% e 31%, respectivamente, tornando a otimização mais eficiente do que há 11 anos
  • Rastreamento, dados de publicidade e outros elementos desnecessários foram totalmente excluídos, com forte foco na privacidade do usuário

Uso de IA

  • Durante o processo de reconstrução do site, o Chat GPT foi usado ativamente para resolver vários problemas de desenvolvimento, como CSS, sugestão de ícones, configuração do Cloudflare e particularidades do .NET Core
  • Com sugestões rápidas e automação de código por IA, houve um grande aumento de produtividade
  • Também foi confirmada alta precisão e utilidade em tarefas como migração rápida e automação de trabalho

Jornada de desenvolvimento e conclusão

  • Diversos trabalhos invisíveis, como atualização de documentos legais, consumiram muito tempo e custo
  • Antes e depois do lançamento, problemas foram resolvidos rapidamente por meio de várias correções urgentes e lançamentos iterativos
  • Sem perder a proposta original, o serviço concluiu seu recomeço preservando especialização, escalabilidade e conforto de uso
  • Desde 2013, o HIBP é o resultado de uma paixão à qual foi dedicado um quarto da vida, e com esta versão 2.0 espera-se um novo salto como serviço para a comunidade

1 comentários

 
GN⁺ 2025-05-20
Comentários do Hacker News
  • Compartilhou a ideia de fazer parceria com escritórios de advocacia para incentivar ações coletivas em todos os vazamentos causados por negligência (ou seja, praticamente todos), e integrar isso a serviços bancários de pagamento para transferir acordos diretamente a milhões de pessoas; assim, isso poderia transformar o projeto em um herói moderno. Destacou a importância de trabalhar com advogados capazes de obter decisões realmente duras contra empresas culpadas, alertando que acordos pequenos e simbólicos podem acabar incentivando a continuidade de gestões irresponsáveis. Também mencionou, de forma opcional, a possibilidade de vender dados sobre processos iminentes para investidores e, no fim, criar um ambiente social em que só a notícia de um vazamento já prejudique naturalmente as ações da empresa
    • Disse que, se fosse possível doar imediatamente uma pequena parte de cada indenização para uma boa causa, isso talvez aumentasse a motivação para participar de ações coletivas
    • Brincou que, sobre esse serviço bancário, a dúvida é quanto tempo levaria até os próprios dados guardados nesse sistema também vazarem
    • Demonstrou preocupação de que um sistema assim possa ter o efeito contrário: como as empresas já relutam em divulgar vazamentos, essa estrutura só aumentaria o risco e faria com que evitassem ainda mais a divulgação. Disse que prefere saber se seus dados vazaram para poder trocar a senha
    • Reclamou que ainda está esperando o dia em que será compensado pela Blue Shield pelo fato de seus dados pessoais terem sido vendidos ao Google, mas mesmo assim disse que usaria o serviço
  • Surpresa pelo fato de que, até há menos de 10 anos, um site enorme como o LinkedIn armazenava senhas sem salt; questionou como um erro desses ainda podia acontecer nos tempos modernos
    • Explicou que esse tipo de problema pode surgir de forma não intencional com mais facilidade do que parece. Do ponto de vista de um middleware, o campo password dentro de um JSON pode ser visto apenas como mais um campo, e se a API ou o sistema de logs registrar o corpo inteiro da requisição, o problema pode de fato acontecer. Disse que é raro salvar diretamente senhas sem salt em um repositório de senhas, mas compartilhou a experiência de que algo parecido pode ocorrer, por exemplo, quando um gateway de API de um app Android deixa de tratar um fluxo como “esqueci minha senha” como informação sensível
    • Fez uma piada dizendo que esses erros acontecem porque nas entrevistas de engenharia não cobram problemas Leetcode Hard o suficiente
    • Observou que se fala muito sobre AI Slop, mas que o problema de Outsourced Slop já existe há muito tempo e é igualmente sério. Comentou, com base na experiência, que há grande chance de o LinkedIn também ter sofrido por entregas de programadores terceirizados. Defendeu que só gestores fortes e competentes, que definem e verificam padrões de qualidade, conseguem evitar produtos que parecem bons por fora, mas são frágeis por dentro
    • Sugeriu que esse tipo de erro também pode vir de sistemas legados antigos, como mainframes montados no passado e depois abandonados porque ninguém consegue investir tempo ou orçamento em manutenção e migração. Apontou o problema estrutural de grandes empresas, onde a ossificação de sistemas críticos é tão forte que até uma interrupção de uma hora já é tratada como “prejuízo” de milhões de won, tornando qualquer manutenção ainda mais impossível
  • Disse que muita gente comum usa o Have I Been Pwned com frequência e que direcionar usuários para o 1Password parece uma das melhores escolhas. Comentou que a promoção com o 1Password combina muito bem e sugeriu que o texto do banner ficasse mais chamativo, algo como “recomendado fortemente”. Ressaltou que a maior parte dos sequestros de contas em redes sociais vem da reutilização de senhas e que, por isso, educar sobre senhas seguras e levar as pessoas a um gerenciador de senhas é algo muito positivo. Compartilhou que ajudou a resolver mais de 20 casos reais ao longo do último ano e parabenizou pelo redesign
  • Achou assustadora, mas impressionante, a funcionalidade que mostra todos os vazamentos em uma rolagem vertical com logos e textos de apresentação
    • Comentou, com resignação, que olhar vazamentos gera uma sensação de impotência e que, fora congelar o crédito, quase não há nenhuma medida prática a tomar
  • Perguntou quem teria o recorde de maior número de vazamentos registrados. Compartilhou que seu e-mail principal já apareceu em 40 vazamentos: o mais antigo em junho de 2011 (HackForums, do qual nem se lembra) e o mais recente em setembro de 2024 (FrenchCitizens, sem qualquer relação com a França)
    • Outra pessoa respondeu que ultrapassou esse recorde por 1 caso
    • Compartilhou o impressionante registro de que o e-mail john@yahoo.com apareceu em nada menos que 322 vazamentos
  • Deu a dica de que, para quem quer um pouco mais de privacidade, existe uma função de opt-out no serviço para ocultar os resultados de busca do próprio e-mail
  • Disse que usa vários aliases de e-mail e por isso não consegue pesquisar um por um; gostaria de uma função para pesquisar tudo de uma vez pelo domínio
    • Informou que, na seção "The Domain Search Feature", é possível verificar a propriedade do domínio e ver todos os resultados de uma vez
  • Comentou que o site é realmente excelente e desejou que os governos levassem esse problema mais a sério. Enfatizou que roubo de identidade, tomada de contas e problemas semelhantes no fim começam com vazamentos de dados, e que hoje ter contas digitais comprometidas é um desastre maior do que um ladrão invadir a própria casa. Observou que, em casos de invasão física, existem canais claros de denúncia e rastreamento, como o 911, enquanto em violações digitais não há nem contato nem processo real de resolução, e pediu uma mudança na resposta social
  • Avaliou o redesign de forma muito positiva e disse que acompanhar as atualizações do Troy também é divertido, embora às vezes pareça um tipo de humor sombrio. Comentou que a linha do tempo parece estar ordenada do vazamento mais antigo para o mais recente, mas achou confuso que a data exibida não seja a do momento em que os dados vazaram, e sim a da divulgação pública do vazamento. Sugeriu como solução que tanto a ordenação quanto a exibição usem claramente a “data de divulgação”, enquanto a data real do vazamento apareça dentro do cartão em um formato padronizado