Have I Been Pwned 2.0 공개

 (troyhunt.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 오래 준비된 HIBP 리브랜딩이 실제 서비스로 전환되며, 웹사이트 전면 재구축과 거의 모든 페이지의 기능 개편이 함께 공개됨
  • 메인 검색은 결과 경험을 개선했지만 웹사이트에서는 username·phone number 검색을 제거하고, 기존 API 호환성은 유지함
  • 새 침해별 페이지는 검색 결과를 덜 복잡하게 만들고, 사고 이후 사용자가 취할 수 있는 구체적 대응 안내를 별도 화면으로 분리함
  • 이메일 접근 검증이 필요한 기능은 Sign In 기반 대시보드로 묶였고, domain search는 JSON API와 클라이언트 측 필터링으로 더 빠르게 동작함
  • 기술 스택은 Azure, Cloudflare,.NET 9.0, Bootstrap, TypeScript 중심으로 정리됐으며, Google reCAPTCHA를 제거하고 Cloudflare Turnstile만 사용함

새 웹사이트와 검색 경험

  • 새 Have I Been Pwned 웹사이트가 공개됨
    • 공개 저장소의 리브랜딩 작업 첫 커밋은 2024년 2월에 이뤄짐
    • 새 브랜드는 2025년 3월에 소프트 런칭됨
    • 이번 릴리스에는 웹사이트 전면 재구축, 거의 모든 페이지 기능 변경, 새 기능 추가, 굿즈 스토어 공개가 포함됨
  • 메인 검색 박스는 HIBP의 대표 기능을 유지하되 결과 표시 방식을 바꿈
    • 일부 사용자는 축하 반응과 confetti 애니메이션을 보게 됨
    • 침해가 확인된 경우에는 더 차분한 빨간 응답을 보여줌
    • 결과는 역시간순으로 스크롤 가능한 timeline 형태이며, 각 침해의 개요를 함께 제공함
  • 웹사이트 검색에서는 username과 phone number 지원이 제거됨
    • username 검색은 2014년 Snapchat incident를 위해 도입됨
    • phone number 검색은 2021년 Facebook incident를 위해 도입됨
    • 두 데이터 유형은 그 두 사례 외에는 로드된 적이 없음
    • username은 소유자를 특정하기 어렵고, phone number는 국제 형식과 표기 차이 때문에 파싱이 까다로움
    • SMS 알림은 이메일보다 비용이 매우 높음
    • 기존 사이트에서 이 입력을 허용하면서 “왜 내 번호가 특정 침해에 없느냐”는 혼란과 지원 부담이 생김
    • API에서는 호환성 유지를 위해 계속 지원하지만, 추가 데이터가 들어갈 것으로 기대하지 말라고 밝힘

침해별 전용 페이지

  • 새 breach page는 메인 검색 결과가 너무 복잡해지는 문제를 줄이기 위해 침해별 상세 정보를 별도 화면으로 분리함
  • 페이지의 핵심 변화는 침해 이후 사용자가 취할 행동을 더 구체적으로 안내하는 데 있음
    • 침해를 당한 사용자가 무엇을 해야 하는지에 초점을 둠
    • identity protection provider 같은 파트너 서비스와 연결하는 방향도 포함함
  • 향후 침해와 사용자별 데이터를 더 보강할 계획임
    • 해당 서비스가 2FA를 지원하면 일반 안내 대신 이를 구체적으로 표시함
    • passkey도 별도 섹션으로 추가할 예정임
    • 영국 NCSC와의 논의에서는 영국 사용자에게 NCSC 로고와 관련 안내 리소스를 보여주는 지역화된 데이터 유출 가이드를 다룸

통합 대시보드와 도메인 검색

  • 이메일 주소 접근 확인이 필요한 기능이 여러 해 동안 늘어나면서, 이를 하나의 central dashboard로 통합함
    • 2015년 Ashley Madison 사건 때 sensitive breach 개념이 도입되며 이메일 수신을 통한 확인이 필요해짐
    • 2019년 API 남용을 줄이기 위해 API에 인증 계층을 추가했고, API key 구매 전 이메일 검증을 요구함
    • 이후 domain search dashboard, 유료 구독 관리, stealer logs 조회가 추가됨
  • 새 대시보드는 하나의 Sign In 뒤에서 이메일 주소 접근을 검증한 뒤 관련 기능을 보여줌
    • 대중용 기능과 비즈니스 지향 기능이 함께 들어감
    • 향후 이메일 전송 없이 로그인할 수 있도록 passkey 지원을 추가할 계획임
    • 가족의 이메일 주소를 알림 구독에 등록하되 알림은 다른 주소로 받는 기능도 대시보드에 어울리는 예시로 다뤄짐
  • domain search에는 화면 정리와 필터링 개선이 많이 들어감
    • 검증된 도메인 목록이 더 깔끔해짐
    • 검색 결과는 더 명확한 요약을 제공함
    • 이메일 주소별 필터링과 “latest breach만 보기” 필터가 추가됨
  • 도메인 검색 대시보드는 API에서 JSON을 받고 전체 대시보드가 단일 페이지 앱처럼 동작함
    • 필터링은 전체 domain search JSON을 대상으로 클라이언트 측에서 수행됨
    • 25만 개가 넘는 침해 이메일 주소가 있는 도메인에서도 동작 가능함을 테스트함
    • 다만 그런 규모의 데이터는 브라우저에서 스크롤하기보다 API로 받는 편이 더 적절함
  • 도메인 소유권 검증도 완전히 다시 작성됨
    • 더 깔끔하고 단순한 인터페이스로 바뀜
    • 이메일 외 검증 방식은 아직 더 매끄럽게 만들 작업이 남아 있음

API 문서와 굿즈 스토어

  • API 자체에는 변경이 없음
    • 이번 업데이트는 호환성을 깨는 변경을 만들지 않음
    • 기존 API 사용자는 깨지는 부분이 없음
  • API 문서는 새 방식으로 전환하지 못하고 기존 문서를 유지함
    • UX rebuild GitHub repo에서 API 문서화 방식에 대한 논의가 있었고, 일반적 합의는 OpenAPI였음
    • Scalar를 이용한 작업이 진행됐고 haveibeenpwned.com/scalar에서 볼 수 있음
    • Scalar는 여러 언어의 샘플과 브라우저 내 테스트 러너를 제공함
    • 큰 런칭 일정 안에서 완성하지 못해 기존 API 문서를 새 사이트 스타일로 맞춰 유지함
    • 향후 여유가 생기면 Scalar 구현으로 전환할 계획임
  • HIBP 굿즈 스토어가 merch.haveibeenpwned.com에 공개됨
    • Teespring을 통해 운영됨
    • 모든 상품은 원가로 판매되며 수익을 내지 않음
    • 커뮤니티를 위한 재미있는 시도로 마련됨
  • 스티커는 Teespring 옵션이 기존 Sticker Mule 품질에 못 미쳐 기존 Sticker Mule store를 계속 사용함

기술 스택과 성능

  • 원본 서비스는 계속 Microsoft Azure에서 운영됨
    • 웹사이트는 App Service를 사용함
    • 대부분의 API는 serverless Functions를 사용함
    • SQL Azure Hyperscale, queues, blobs, tables 같은 storage account 기능을 사용함
    • 코드는 대부분 C#이며, .NET 9.0과 ASP.NET MVC on .NET Core를 사용함
  • Cloudflare도 계속 큰 역할을 맡음
    • Workers에 많은 코드가 있음
    • R2 storage에 데이터가 있음
    • WAF와 caching 기능을 사용함
    • anti-automation은 Cloudflare Turnstile만 사용하고 Google reCAPTCHA는 완전히 제거함
  • 프런트엔드는 최신 Bootstrap 세대, SASS, TypeScript를 사용함
    • CSS는 SASS로 작성됨
    • JavaScript는 TypeScript로 작성됨
  • 웹사이트 성능도 측정 가능한 개선이 있음
    • Pingdom 테스트 기준으로 페이지 크기를 28% 줄임
    • 요청 수를 31% 줄임
    • 로드 시간은 변동성이 커 큰 차이를 단정하지 않음
    • 11년 뒤에도 웹페이지 크기와 요청 수에서 두 자릿수 비율을 줄였다는 점을 강조함
  • 추적이나 광고성 부하로 볼 수 있는 요소는 넣지 않음
    • 실제 트래픽 통계는 Cloudflare edge node를 지나는 트래픽 기반임
    • 1Password product placement는 텍스트와 이미지뿐임
    • outbound click도 추적하지 않음
    • 침습적 추적 수치를 기대하는 identity theft 회사와의 product placement 논의는 더 어려워짐

개발 과정에서의 AI 활용

  • ChatGPT는 재구축 과정, 특히 마지막 며칠 동안 광범위하게 사용됨
    • Bootstrap icons에서 “Index” heading에 맞는 아이콘을 찾는 데 활용됨
    • 2,000개가 넘는 아이콘 중 적절한 것을 약 30초 안에 찾는 식으로 쓰임
  • 사이트 이전 확인에도 AI가 쓰임
    • haveibeenpwned.com을 크롤링해 고유 URL을 출력하는 PowerShell script를 작성하게 함
    • 발견한 path가 stage.haveibeenpwned.com에 존재하는지 확인하는 script도 작성하게 함
    • 누락된 security.txt 파일을 찾는 데 도움이 됨
    • 존재한 적 없는 항목도 찾아내 “trust, but verify”가 필요했음
  • CSS 조언, Cloudflare rule 설정, .NET Core 웹앱 특이점 같은 작은 작업에도 활용됨
    • 답이 맞았던 비율을 약 90% 로 평가함
    • 소프트웨어 개발에서 AI를 적극적으로 쓰지 않는다면 잘못하고 있다고 말할 정도로 강하게 긍정함

런칭과 Turnstile 이슈

  • 새 사이트는 작성자 기준 일요일 이른 아침에 배포됨
    • 거의 모든 것이 잘 진행됐고, 작은 glitch 한두 개는 빠르게 수정해 배포함
    • 글은 라이브 2일 뒤에 공개해 먼저 문제를 최대한 정리함
    • 그 사이 12개가 넘는 새 릴리스를 배포하며 빠르게 반복 개선함
  • 약관과 개인정보 처리방침 같은 작은 변경에도 많은 시간이 들어감
    • 데이터 처리 방식의 작은 업데이트와 stealer logs 같은 새 서비스 반영이 필요했음
    • 변호사와의 작업에 여러 시간과 수천 달러가 들어감
  • Cloudflare Turnstile은 Google reCAPTCHA처럼 트래픽을 Google로 넘기지 않는 anti-automation 방식임
    • 완전히 보이지 않게 구현할 수 있음
    • 브라우저에서 Cloudflare script가 challenge를 만들고, HTTP 요청과 함께 제출된 뒤 서버 측에서 검증됨
    • HIBP에는 2023년부터 어떤 형태로든 적용돼 있었음
  • 이메일을 보내는 폼처럼 봇 차단이 중요한 곳에서는 Turnstile 실패 시 사용자에게 다시 시도하거나 페이지를 새로고침하라는 안내를 표시함
    • 두 번째 클릭이나 페이지 reload로 해결되는 경우가 자주 있었음
    • 해결되지 않으면 사용자가 상호작용해야 하는 더 눈에 띄는 Turnstile widget 구현을 검토해야 함
  • 메인 검색 페이지에서도 Turnstile이 중요하게 사용됨
    • 비동기로 API endpoint에 요청하며 challenge token을 함께 보냄
    • challenge 실패로 HIBP endpoint가 HTTP 401과 Invalid Turnstile token을 반환하면 full page post로 fallback해야 했음
    • 새 사이트 최초 런칭 때는 이 fallback이 동작하지 않았지만 이후 수정됨
    • full page post에서는 Cloudflare managed challenge가 표시되며, 더 침습적이지만 더 신뢰성 있음
  • Cloudflare 통계 기준 발급된 challenge의 약 82% 가 성공적으로 해결됨
    • 해결되지 않는 18% 중 상당수는 Turnstile이 의도대로 차단한 봇일 수 있음
    • 실제 사람이 막힌 요청은 한 자릿수 비율일 가능성이 있으며, 이 수치를 낮추는 방법을 계속 봐야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 과실로 인한 모든 유출에 대해 집단소송을 걸 수 있도록 로펌과 손잡는 게 좋겠음. 은행 서비스와 연결해서 새 합의금이 지급될 때마다 수백만 명에게 바로 입금되게 하면 민중의 영웅이 될 수 있음
    회사가 책임 있게 운영하는 것보다 작은 합의금을 영업 비용으로 처리하는 쪽이 낫다고 느끼지 못하게, 판결금이 실제로 아픈 수준이 되도록 만들 변호사들이 필요함
    선택 사항으로는 임박한 소송 데이터를 투자회사에 팔 수도 있겠지만, 이상적으로는 유출이 곧 주가 하락을 의미한다는 걸 모두 알게 되어 그런 데이터가 필요 없어지는 게 맞지 않나 싶음

    • 정말 미국식 반응임. 모두를 고소하고 변호사만 돈을 벌지만 결국 바뀌는 건 없음
      EU에는 NIS2 같은 법이 있고, 준수 의무를 소홀히 하면 벌금이 1천만 유로 또는 전 세계 연매출의 2% 임. 예를 들어 Apple이 80억 달러 벌금을 맞으면 꽤 많은 게 바뀔 것 같음
    • 새 합의금이 나올 때마다 아주 작은 금액을 받느니, 그 소액 합의금을 쉽게 좋은 곳에 기부할 수 있으면 좋겠음. 그러면 집단소송 등록에 시간을 쓰는 보람도 생길 듯함
    • 이건 부정적인 효과가 있을 것 같음. 지금도 회사가 유출을 공개 발표하게 만드는 건 어려운데, 이런 제안은 그걸 더 어렵게 만들고 결과 때문에 더 많은 데이터 유출이 공개되지 않을 수 있음
      차라리 회사가 사고를 냈다는 걸 알고 비밀번호를 바꾸는 편이, 아무것도 모르는 것보다 낫다고 봄
    • 그렇게 수백만 명에게 직접 입금하려면 모아야 하는 그 은행 연동 데이터는 얼마나 지나서 유출될까 싶음
    • 사용자에게는 아마 푼돈을 지급하려고 엄청난 결제 인프라를 바꾸는 셈이고, 플랫폼에는 큰 유지보수 부담이 생김. 결제는 악몽 같은 시스템인데, 소송으로 돈 버는 로펌과 브랜드 호감도만 과도하게 이득 볼 듯함
      꽤 별로인 거래로 보임

  • 많은 사람처럼 “주” 이메일 주소가 있고, 거의 모든 다른 곳에는 회사별 주소를 씀. 그런데 도메인 검색이 구독제로 바뀌면서 이 사이트의 유용성이 훨씬 떨어졌음
    방금 도메인을 다시 추가해 보니 “2,243 Total Breached Addresses”, “18 Addresses excluding Spam Lists”가 보이지만 그 주소들이 무엇인지는 알 수 없음. 링크를 클릭하면 보려면 “upgrade”하라고 나오고, Excel과 JSON 다운로드는 404가 남
    이메일 하나만 쓰는 사람에게는 알림용으로 좋을 수 있지만, 여러 주소가 있는 도메인을 쓰면 훨씬 덜 유용해짐

    • 개인용 캐치올 도메인을 꽤 많이 갖고 있고, 주요 도메인 두 개는 사이트별 별칭에 쓰고 있어서 10년 넘게 지난 지금은 각 주소를 수동으로 입력할 수도, 기억할 수도 없음
      도메인 검색 구독 제한은 짜증 나지만 Troy와 가족도 먹고살아야 하니 유료 영역이 필요한 건 이해함. 특히 회사 대상이라면 더 그렇고, 우리는 그 사이의 회색 지대에 걸린 셈임
      좀 더 세분화되면 좋겠지만, HIBP가 개발자와 고객지원 인력을 많이 뽑지 않는 한 모든 예외 사례를 맞춰줄 수는 없겠음. 결국 구독해서 도메인을 확인한 뒤 취소했는데 조금 번거롭지만 괜찮았음. 반복 결제가 아닌 2일 이용권이 있었으면 딱 맞았을 듯함
    • 나도 이 회색 지대에 있음. 도메인당 최대가 10개 정도인 것 같은데, 마지막으로 확인했을 때 11개나 12개가 유출돼서 이제 볼 수 없게 됐음
      사이트별 주소를 쓰는 개인은 무료로 접근하면서도 회사에는 결제를 요구할 수 있는 쉬운 해법은 잘 모르겠지만 아쉽긴 함
    • 비슷한 설정으로 한 도메인에서 많은 주소를 쓰고 있음. 그런데 구독 중은 아닌 것 같은데도 내 도메인에서 와일드카드 검색이 문제없이 되고, 어떤 이메일이 유출됐는지도 정확히 볼 수 있음
      어떤 유출에 포함됐는지는 보이지 않지만 덜 중요함. 이메일마다 제품, 프로젝트, 회사 하나에 대응하니 어디서 샜는지는 이미 알 수 있음
    • 예전에는 이메일에 +something만 붙였지만, 지금은 더 신경 써서 마스킹된 이메일을 만들려고 함. 처음에는 어리석게도 내 도메인으로 만들었지만 이후에는 @fastmail.com으로 만들고 있음
    • 회사별 주소가 주 이메일 주소에서 파생된 형태라면, 이건 이메일 텀블링(email tumbling) 이라고 부름. “회사별” 부분을 제거해서 주 이메일을 드러내는 서비스들이 있음

  • 기사에 나온 차단 시 대안이 “박스를 다시 클릭해 보라”와 “페이지를 새로고침해 보라”라니, 이제 차단당하면 다른 곳으로 가는 대신 회사에 종이 우편을 보내야 하나 싶어짐
    HIBP는 무료 웹 서비스이고 상점이 특정 개인에게 서비스를 제공할 의무는 없지만, 모두가 Cloudflare Turnstile, Google reCAPTCHA 등을 앞세우면 “한 자릿수 비율”의 사람들은 현대 사회에 참여할 수 없게 됨
    봇 대역으로 잘못 분류된 IP, 특이하거나 오래되거나 감염된 브라우저 같은 비슷한 표식은 같은 집단에게 계속 걸릴 것임

    • 이전 직장에서 이런 필터링 조치에 꽤 급진화됐음. 인기 있는 공개 웹사이트를 운영했는데, 어떤 휴리스틱에 따라 정상 로그인을 거부하는 서드파티 솔루션을 도입했고 일부러 모호한 “나중에 다시 시도”식 오류를 냈음
      몇 달 동안 내부 채팅에서 동료들이 똑같은 오류로 로그인하지 못한다고 꾸준히 말하는 걸 봤고, 긴급도도 제각각이었음. 나도 개인 탐색 창에서는 로그인할 수 없었지만 오래 유지된 세션 쿠키가 살아 있어서 크게 걱정하지 않았음
      회사 내부 사람들조차 이런 필터의 피해자가 된다면 일반 대중은 무슨 기회가 있겠나 싶음. 실제로 오래된 제품 사용자였던 친구들도 사이트에서 잠겼고, 그들이 사기 탐지 휴리스틱의 오탐이라는 걸 이해하거나 개별 지원을 받을 방법은 없었음
      서비스 남용 대응의 필요성은 이해하지만, 친구들과 내가 상황이 나빠지면 쉽게 희생될 수 있다는 걸 깨닫고 회사와 업계에 대한 애정이 크게 줄었음
    • 6시간 뒤에 바로 사례가 생김. 보이지 않는 CAPTCHA 때문에 Slack 로그인에서 차단당했음: https://snipboard.io/h1E86S.jpg
      이메일로 받은 코드를 잘못 입력한 줄 알았는데 아니었음. 개발자 도구를 보니 서버가 나를 다시 “bot”으로 판정했다고 드러냄. 보이지 않는 절차라 할 수 있는 게 없음
      이 브라우저는 회사 웹사이트 침투 테스트용이라 깨끗함. 애드온도, uBlock도, NoScript도, 회사 설정도 아무것도 없음
    • 동의함. 내 고정 IP 주소가 어떤 이유로 Google과 Cloudflare를 트리거하는 것 같음. 집에서 스크래퍼 같은 걸 돌리지는 않지만 NoScript를 쓰는데, NoScript를 쓰면 봇인가 싶기도 함

  • 새 디자인이 덜 신뢰가 가는 느낌이 드는 사람이 또 있나? 똑같아 보이는 템플릿들에 너무 길들여진 탓일 수 있고 본질적으로 잘못된 건 없지만, 진짜 사이트가 아니라 가짜 사이트를 잘못 연 건가 싶어짐

    • 동의함. 새 버전은 저렴한 템플릿에 싼 느낌의 그라데이션을 쓴 것처럼 보이고, 즉시 신뢰도가 낮아 보임
    • 나이 든 까칠한 사람이라 그런 걸 수도 있지만, 웹사이트 재설계는 대체로 마케팅용이고 웹 개발자에게는 재미있을 뿐 사용자에게 도움이 되는 경우는 드묾
      Nasa ADS는 오랫동안 아주 오래돼 보이지만 깔끔하고 빠르며 할 일을 하는 훌륭한 사이트였는데, 사진과 JavaScript로 꾸미는 데 많은 시간과 노력을 들였고 지금도 결국 같은 일을 할 뿐임
    • 성능도 끔찍하고 스크롤 가로채기까지 함. 사이트 느낌이 아주 나쁨

  • 최근 10년 안에도 LinkedIn처럼 큰 사이트가 솔트 없는 비밀번호를 저장했다는 게 놀라움. 현대에 어떻게 이런 걸 실패할 수 있나

    • 의도치 않게 그렇게 되기는 사실 아주 쉬움. 중간 미들웨어 입장에서는 JSON 객체 안의 비밀번호 필드도 다른 필드와 똑같은 JSON 필드일 뿐임
      어딘가에서 요청 본문을 기록하는 로깅, 추적, 분석 시스템이 있을 수 있음. 마케팅 장난까지 갈 필요도 없고, 그 규모에서는 필수인 남용 방지 시스템만으로도 문제가 생길 수 있음
      “비밀번호 데이터베이스”에 솔트 없는 비밀번호를 저장하는 일은 흔치 않지만, 예컨대 Android 앱 API 게이트웨이의 요청 로그를 저장하면서 비밀번호 재설정 흐름의 password 필드를 민감 정보로 표시하는 걸 잊는 일은 그리 드물지 않음
    • 면접에서 LeetCode Hard 문제를 충분히 많이 묻지 않았나 봄
    • LinkedIn은 한때 연락처를 쉽게 찾게 해준다는 명목으로 사람들에게 이메일 자격 증명을 넘기라고 계속 압박했음
      그러니 LinkedIn이 IT 보안의 보루였던 적은 딱히 없음
    • 참고로 같은 회사가 MFA를 활성화하려면 가입 때는 필요 없던 여권과 연결된 얼굴 생체 스캔을 “verification” 명목으로 업로드하라고 요구함
      관련해서 나는 더 이상 활성 LinkedIn 계정이 없음
    • 기억이 맞다면 LinkedIn 유출 때 내 LinkedIn용 주소로 스팸이 와서 알려줬더니, 처음에는 “우리일 리 없고 당신이 해킹당했을 것”이라고 했음
      나중에는 “아 맞다 우리였지만 개인정보는 도난당하지 않았다”고 했음. 이메일 주소가 개인정보가 아니라는 식이라니, 캐치올 도메인을 써서 LinkedIn에 쓴 주소만 차단할 수 있었던 게 다행임

  • 아쉽게도 새 UI에서는 더 이상 유출된 전화번호를 검색할 수 없음. 예전 UI에서는 가능했음. 예를 들어 Facebook 전화번호 유출 확인은 https://www.troyhunt.com/the-facebook-phone-numbers-are-now-...에서 볼 수 있음
    공지에도 “웹사이트에서 사용자명과 전화번호 검색 지원을 제거했다”고 적혀 있음
    그런데 독일에서 Facebook을 상대로 진행 중인 소송(https://www.vzbv.de/pressemitteilungen/facebook-datenleck-be..., 독일어 링크)이 있고, 참여 가능 여부를 알기 위해 그 검색을 활용하던 상황이라 지금 이 기능을 없애기엔 정말 안 좋은 시점임

    • API는 여전히 지원하므로 이를 위한 새 솔루션 구현은 가능할 것 같음
      공지에 나온 기능 제거 이유는 더 큰 영향을 고려하면 꽤 합리적으로 보임

  • 이메일을 노출한 모든 데이터 유출을 로고와 설명이 있는 세로 스크롤 타임라인으로 보여줌. 기분 좋게 끔찍함

    • 조금 무력하게 느껴짐. 현실적으로 할 수 있는 건 신용 동결뿐임

  • 조금 더 눈에 띄지 않고 싶은 사람은 이 서비스의 이메일 검색 결과에서 숨길 수 있음
    https://haveibeenpwned.com/OptOut

    • 이메일 인증 뒤에 보이는 탈퇴 선택지는 3가지임
      1. 공개 검색에서만 내 이메일 주소 제거: 공개 HIBP 검색 결과에는 나오지 않지만, 이메일 소유권을 확인하는 알림 서비스를 통해서는 본인이 계속 검색할 수 있음. 누군가가 내 이메일 도메인을 모니터링 중이라면 도메인 수준 검색에서는 계속 볼 수 있음
      2. 공개 검색에서 내 이메일 주소를 제거하고, 해당 주소가 포함된 유출 목록 삭제: 공개 서비스나 본인 인증 검색으로도 더 이상 검색되지 않음. 다만 향후 유출에 제외되도록 이메일 주소 자체는 HIBP에 남아 있음
      3. 내 이메일 주소 완전 삭제: 삭제 시점에는 본인과 공개 모두 검색 결과에 나오지 않지만, 향후 데이터 유출에 다시 포함되면 opt-out 기록도 사라졌기 때문에 다시 공개 검색 가능해짐
    • opt-out 목록이 털리면 어떻게 될까

  • 일반 사람들도 Have I Been Pwned를 많이 쓰니, 그들을 1Password로 보내는 건 아마 가장 좋은 일 중 하나일 수 있음. 스폰서십인 건 알지만 매우 잘 맞는 스폰서임
    프로모션 배너 문구를 “강력히 권장합니다”처럼 더 세게 하고 페이지에서도 더 눈에 띄게 만들겠음
    공유 비밀번호 때문에 해킹되는 소셜 미디어 계정이 정말 많고, 피해자들이 결국 이 사이트에 오는 경우가 많음. 이들을 비밀번호 관리자와 좋은 보안 습관으로 유도하는 건 훌륭함
    지난 약 12개월 동안 그런 사례를 20건 넘게 도와준 것 같음

    • 스폰서십이라 불평하는 건 아니지만, 정말 사람들에게 비밀번호 관리자를 쓰게 하는 게 목표라면 Bitwarden으로 보내는 게 맞았을 것임. 무료 플랜이 있고, 유료 플랜도 1Password의 연 36달러보다 훨씬 싼 연 10달러임
    • 왜 Bitwarden은 아닐까

  • 이 사이트 자체가 취약점처럼 느껴지지 않나? 아무 이메일 주소나 입력해서 발견된 사이트 목록을 얻을 수 있다면 공개 출처 정보 수집(OSINT) 절차의 일부가 될 것 같음
    결과를 보여주기 전에 최소한 그 주소를 제어한다는 확인 링크를 보내야 하지 않나

    • 합리적인 절충이라고 봄. 비기술 사용자에게는 자신의 데이터가 유출됐는지, 어떤 비밀번호를 재설정해야 하는지 볼 수 있는 매우 유용한 서비스임
      악의적 행위자에게는 빠른 조회와 몰랐던 유출 정보를 제공해 조금 더 쉽게 만들어주지만, HIBP가 없더라도 결국 다크웹 버전이 생겼을 것임
      HIBP 같은 사이트는 홍보 효과도 큼. “Big Corp 고객 기록 4억 건 유출” 같은 헤드라인은 추상적으로 느껴지지만, HIBP에 이메일을 입력하고 내 이메일과 다른 데이터가 유출된 회사 목록을 보면 훨씬 개인적으로 다가옴
    • 악의적 행위자는 어차피 데이터에 접근할 수 있다는 가정이라, 그런 확인 절차를 둬도 악의적 행위자를 전혀 막지 못한다고 보는 듯함
    • 이건 실제로 OSINT 절차의 일부임. 늘 그랬음
    • 대부분의 온라인 범죄자는 이미 이 데이터를 갖고 있거나 조금만 조사해도 얻는 법을 알기 때문에 99%의 경우 큰 문제는 아님. 순효과로 보면 나쁜 점보다 좋은 점이 훨씬 크다고 봄
    • 나도 정확히 같은 느낌을 받았음. 특히 내 이메일이 Trump 선전으로 가득한 수상한 보수 뉴스 사이트에 등록되고 유출된 걸 봤기 때문임
      사람들이 남을 쓰레기 “악성 구독”에 가입시킬 수 있다는 건 알고 있었고, 그런 메일이 받은편지함에 올 때 그 일이 벌어진 거라고 의심했지만, 이제 다른 사람들도 매우 공개적으로 볼 수 있다는 게 불쾌함
      내가 직접 가입하지 않았다는 걸 남들이 어떻게 알겠나. 사람들이 나를 그렇게 생각할까 봐 싫음
      다행히 https://haveibeenpwned.com/OptOut로 해결되는 것 같음
답변달기