Have I Been Pwned 2.0

• Dịch vụ kiểm tra rò rỉ dữ liệu Have I Been Pwned đã được làm mới hoàn toàn
• Cùng với thiết kế mới, các chức năng của những trang web chính đã được thay đổi và cải thiện đáng kể
• Chức năng tìm kiếm trở nên trực quan hơn, đồng thời tăng cường hướng dẫn về cách kiểm tra tài khoản và các trường hợp vi phạm dữ liệu khác nhau
• Nhiều tính năng mới và cải tiến như bảng điều khiển người dùng, tìm kiếm tên miền, tài liệu API đã được bổ sung
• Hiệu năng web và bảo mật được triển khai trên hạ tầng đám mây hiện đại, mang lại trải nghiệm nhanh và an toàn hơn cho người dùng

---

Giới thiệu và bối cảnh

• Have I Been Pwned (sau đây gọi là HIBP) 2.0 đã chính thức ra mắt dưới diện mạo hoàn toàn mới sau thời gian dài phát triển
• Commit đầu tiên được thực hiện vào tháng 2/2023, sau giai đoạn soft launch và mã nguồn mở vào tháng 3/2024, trang web nay được mở lại với kiến trúc được xây dựng lại toàn diện và nhận diện thương hiệu mới
• Toàn bộ cấu trúc và chức năng của trang đã được cải tổ, đồng thời cửa hàng merchandise cũng được mở

Chức năng tìm kiếm

• Ô tìm kiếm nổi bật ở trang chủ, tính năng tiêu biểu của HIBP, đã được cải tiến để trực quan hơn và có thêm điểm nhấn mới mẻ (hiệu ứng confetti)
• Để tránh tạo cảm giác nặng nề và tiêu cực trong trải nghiệm người dùng, dịch vụ tập trung cung cấp thông tin thực tiễn dựa trên sự thật
• Tìm kiếm username và số điện thoại đã bị loại bỏ khỏi website (nhưng vẫn giữ nguyên trên API)
  • Tìm kiếm dựa trên địa chỉ email phù hợp hơn về mặt phân tích cú pháp, cảnh báo và tính nhất quán của dịch vụ
  • Số điện thoại và username gây gánh nặng xử lý dữ liệu cao nhưng hầu như không được dùng trong thực tế, nên đã bị loại bỏ để giảm nhầm lẫn

Trang tình huống vi phạm dữ liệu

• Mỗi vụ vi phạm dữ liệu giờ đây đều có trang chi tiết riêng
• So với trước đây, bố cục trực quan và dễ nhìn hơn, cung cấp hướng dẫn cụ thể và có thể hành động về mức độ ảnh hưởng và cách ứng phó
• Dự kiến sẽ bổ sung thêm thông tin theo từng khu vực thông qua hợp tác với các tổ chức khác (ví dụ: NCSC)
• Trong tương lai, trang này sẽ bổ sung các thông tin chi tiết như hỗ trợ 2FA, passkey và hướng dẫn phù hợp cho từng người dùng

Bảng điều khiển

• Nhiều chức năng trước đây như kiểm tra vi phạm nhạy cảm, quản lý tên miền, quản lý đăng ký đã được hợp nhất vào một bảng điều khiển thống nhất
• Bảng điều khiển hiện được truy cập dựa trên xác minh email, và trong tương lai sẽ bổ sung thêm các phương thức xác thực mới như passkey
• Đây cũng mở ra khả năng phát triển thành một nền tảng có thể mở rộng thêm các tính năng như cảnh báo cho tài khoản gia đình

Chức năng tìm kiếm tên miền

• Tính năng xác minh/tìm kiếm tên miền đã được thiết kế lại hoàn toàn, với UI gọn gàng hơn và hỗ trợ nhiều bộ lọc như chỉ xem các vụ rò rỉ mới nhất
• Kiến trúc được xây dựng dưới dạng ứng dụng single-page app (SPA) hoàn chỉnh, và kết quả tìm kiếm được cung cấp nhanh chóng dưới dạng JSON thông qua API
• Quy trình xác minh quyền sở hữu tên miền cũng đã được đơn giản hóa lại
• Các phương thức xác thực ngoài email sẽ được cải tiến riêng trong thời gian tới

API

• Trong lần cập nhật này, API hoàn toàn không có thay đổi hay gián đoạn nào
• Tài liệu API đang chuẩn bị áp dụng công cụ Scalar dựa trên OpenAPI, nhưng hiện tại vẫn giữ tài liệu cũ và thống nhất lại theo phong cách mới
• Sau này sẽ chuyển sang tài liệu hiện đại hơn dựa trên Scalar

Merchandise và sticker

• Cửa hàng vật phẩm thương hiệu HIBP đã chính thức mở, bắt đầu bán các sản phẩm như áo thun (dựa trên Teespring, không có lợi nhuận biên)
• Sticker vẫn tiếp tục được bán qua cửa hàng Sticker Mule, và artwork được mở nguồn để mọi người có thể tự do sử dụng

Công nghệ và hạ tầng

• Backend của trang chạy trên Microsoft Azure, sử dụng App Service, Functions, Hyperscale SQL, Storage và nhiều dịch vụ khác
• Ứng dụng web chính được viết bằng C# và .NET 9.0, ASP.NET MVC (.NET Core)
• Cloudflare được sử dụng hiệu quả cho WAF, caching, Turnstile (chống bot), R2 storage và nhiều thành phần khác
• Ở frontend, giao diện hiện đại được xây dựng dựa trên Bootstrap mới nhất, SASS và TypeScript
• Nhờ đóng góp của các thành viên nòng cốt như nhà phát triển Ingiber ở Iceland, sản phẩm đạt được độ hoàn thiện cao và UI đẹp mắt
• Dung lượng trang web và số lượng request đã được cắt giảm lần lượt khoảng 28% và 31%, giúp tối ưu hiệu quả hơn so với 11 năm trước
• Tracking, dữ liệu quảng cáo và các thành phần không cần thiết đã bị loại bỏ hoàn toàn, thể hiện sự coi trọng quyền riêng tư của người dùng

Ứng dụng AI

• Trong quá trình xây dựng lại website lần này, Chat GPT đã được sử dụng tích cực để giải quyết nhiều vấn đề phát triển như CSS, gợi ý icon, cấu hình Cloudflare và các điểm đặc thù của .NET Core
• Nhờ các đề xuất nhanh và khả năng tự động hóa mã, nhóm phát triển đã trải nghiệm mức cải thiện năng suất rất lớn
• AI cũng cho thấy độ chính xác và tính hữu ích cao trong các tác vụ như di chuyển hệ thống nhanh và tự động hóa công việc

Hành trình phát triển và kết luận

• Nhiều công việc ít nhìn thấy như cập nhật tài liệu pháp lý đã tiêu tốn rất nhiều thời gian và chi phí
• Trước và sau khi ra mắt, nhiều bản sửa lỗi khẩn cấp và các đợt phát hành lặp lại đã được thực hiện để xử lý vấn đề nhanh chóng
• Dự án đã hoàn tất việc tái khởi động trong khi vẫn giữ vững tính chuyên môn, khả năng mở rộng và sự dễ chịu của dịch vụ
• HIBP là thành quả của niềm đam mê được đổ vào từ năm 2013, chiếm một phần tư cuộc đời, và phiên bản 2.0 được kỳ vọng sẽ trở thành bước nhảy vọt mới cho dịch vụ cộng đồng này

[GN⁺]

Ý kiến trên Hacker News

• Chia sẻ mong muốn rằng nếu hợp tác với các hãng luật để thúc đẩy kiện tập thể với mọi vụ rò rỉ dữ liệu do sơ suất gây ra (thực tế là gần như mọi trường hợp), rồi liên kết với dịch vụ ngân hàng thanh toán để chuyển tiền bồi thường trực tiếp cho hàng triệu người khi có dàn xếp, thì có thể trở thành một kiểu anh hùng thời hiện đại; đồng thời nhấn mạnh tầm quan trọng của việc hợp tác với các luật sư có thể khiến những công ty thực sự cẩu thả phải nhận phán quyết đau đớn, và cảnh báo rằng các khoản dàn xếp nhỏ đơn thuần có nguy cơ khiến kiểu quản lý vô trách nhiệm tiếp diễn. Ngoài ra còn nhắc đến khả năng chọn lọc bán dữ liệu về các vụ kiện sắp diễn ra cho các công ty đầu tư, và cuối cùng mong muốn xây dựng một bầu không khí xã hội nơi chỉ riêng tin tức rò rỉ dữ liệu cũng đủ khiến giá cổ phiếu công ty đó bị ảnh hưởng nặng
  • Bày tỏ mong muốn rằng nếu mỗi khi có tiền bồi thường phát sinh đều có thể quyên góp ngay một khoản nhỏ cho nơi phù hợp, thì sẽ có thêm động lực tham gia kiện tập thể
  • Đùa rằng với dịch vụ ngân hàng đó, chỉ không biết phải mất bao lâu trước khi chính dữ liệu được lưu trong hệ thống ấy lại tiếp tục bị rò rỉ
  • Lo ngại hệ thống như vậy có thể phản tác dụng; trong bối cảnh doanh nghiệp vốn đã rất khó công khai việc bị rò rỉ, cấu trúc này chỉ làm tăng rủi ro và khiến họ càng né tránh công bố hơn; cho rằng biết thông tin của mình đã bị lộ để còn đổi mật khẩu vẫn tốt hơn
  • Than phiền rằng vẫn đang chờ ngày được Blue Shield bồi thường vì thông tin cá nhân của mình bị bán cho Google, đồng thời bày tỏ ý định dùng dịch vụ
• Ngạc nhiên khi chỉ mới trong khoảng 10 năm gần đây mà một trang khổng lồ như LinkedIn lại từng lưu mật khẩu không dùng salt; đặt câu hỏi làm sao thời nay vẫn có thể mắc lỗi như vậy
  • Giải thích rằng kiểu chuyện này trên thực tế có thể xảy ra dễ hơn tưởng tượng. Ở góc nhìn của middleware, trường password trong dữ liệu JSON có thể chỉ bị xem như một trường bình thường khác, và nếu API hoặc hệ thống logging ghi lại toàn bộ request body thì vấn đề thực sự có thể phát sinh. Việc lưu trực tiếp mật khẩu không salt vào kho mật khẩu thì hiếm hơn, nhưng ví dụ nếu tại API gateway của một ứng dụng Android, một flow như “tìm lại mật khẩu” không được đánh dấu là thông tin nhạy cảm thì vấn đề tương tự vẫn có thể xảy ra; đây là chia sẻ từ kinh nghiệm thực tế
  • Ý kiến đùa rằng những sai sót như vậy xảy ra là vì trong phỏng vấn kỹ sư người ta chưa hỏi đủ bài Leetcode Hard
  • Chỉ ra rằng người ta nói nhiều về AI Slop, nhưng thực tế suốt một thời gian dài còn tồn tại nghiêm trọng vấn đề Outsourced Slop; theo kinh nghiệm, khả năng cao sản phẩm của lập trình viên thuê ngoài là nguyên nhân chính trong trường hợp của LinkedIn. Chỉ khi có quản lý mạnh và đủ năng lực đặt ra tiêu chuẩn chất lượng và kiểm chứng thì mới tránh được những sản phẩm nhìn ngoài có vẻ ổn nhưng bên trong lỏng lẻo
  • Cho rằng những sai sót như vậy có thể đến từ các hệ thống cũ như legacy mainframe được xây từ lâu, rồi bị bỏ mặc vì không ai có thời gian hay ngân sách để quản lý và migrate. Càng là doanh nghiệp lớn thì mức độ xơ cứng của các hệ thống quan trọng càng cao, đến mức chỉ dừng khoảng 1 giờ thôi cũng bị xem là thiệt hại hàng trăm triệu đồng trở lên, khiến việc bảo trì lại càng bất khả thi; đây là vấn đề cấu trúc
• Cho rằng rất nhiều người dùng phổ thông thường xuyên dùng Have I Been Pwned, và việc dẫn họ sang 1Password cũng là một lựa chọn tốt nhất. Thực tế, chương trình hợp tác quảng bá với 1Password là sự kết hợp rất phù hợp; còn góp ý rằng câu chữ trên banner nên đổi sang kiểu như "rất khuyến nghị" để nổi bật hơn. Nhấn mạnh rằng phần lớn các vụ tài khoản mạng xã hội bị hack là do tái sử dụng mật khẩu, và từ những trải nghiệm đó thấy việc giáo dục dùng mật khẩu an toàn cũng như đưa người dùng đến với password manager là điều rất tích cực. Chia sẻ rằng trong 1 năm qua bản thân đã trực tiếp hỗ trợ xử lý hơn khoảng 20 vụ thực tế, đồng thời chúc mừng đợt làm mới
• Cảm nhận rằng tính năng hiển thị toàn bộ lịch sử rò rỉ dữ liệu theo dạng cuộn dọc, kèm logo và câu giới thiệu, vừa đáng sợ vừa ấn tượng
  • Tự giễu rằng khi nhìn các vụ rò rỉ dữ liệu thì chỉ thấy bất lực, và ngoài việc đóng băng tín dụng ra gần như chẳng có biện pháp nào để làm
• Tò mò ai là người giữ kỷ lục xuất hiện trong nhiều vụ rò rỉ nhất; chia sẻ rằng email chính của mình đã xuất hiện trong 40 vụ rò rỉ, trong đó cũ nhất là tháng 6/2011 (HackForums, thậm chí không nhớ nổi), còn mới nhất là tháng 9/2024 (FrenchCitizens, chẳng liên quan gì đến Pháp)
  • Có người trả lời rằng mình đã vượt kỷ lục đó đúng 1 vụ
  • Chia sẻ kỷ lục đáng kinh ngạc rằng email [e-mail] đã xuất hiện trong tận 322 vụ rò rỉ
• Gợi ý rằng nếu muốn riêng tư hơn một chút, dịch vụ này có tính năng opt-out để ẩn kết quả tìm kiếm email của mình
• Vì dùng nhiều bí danh email nên không thể tra từng cái một, bày tỏ mong muốn có tính năng tìm kiếm một lần theo domain
  • Hướng dẫn rằng dưới mục "The Domain Search Feature", sau khi xác minh quyền sở hữu domain thì có thể xem kết quả một lượt
• Chia sẻ cảm nhận đây là một trang thật sự tuyệt vời, đồng thời mong chính phủ sẽ nghiêm túc hơn với vấn đề này. Nhấn mạnh rằng trộm danh tính, chiếm đoạt tài khoản và các vấn đề tương tự cuối cùng đều bắt đầu từ các vụ rò rỉ dữ liệu, và ngày nay việc tài khoản số bị xâm nhập còn là thảm họa nghiêm trọng hơn cả bị trộm đột nhập vào nhà ngoài đời thật. Với xâm nhập vật lý thì rõ ràng có 911 để gọi, có truy vết và các bước xử lý, còn với xâm phạm số thì gần như không có nơi liên hệ cũng không có mấy quy trình giải quyết; kêu gọi xã hội cần thay đổi cách ứng phó
• Đánh giá rất tích cực thiết kế làm mới, và nói rằng theo dõi các cập nhật của Troy cũng rất thú vị, dù đôi lúc lại mang cảm giác như một kiểu hài đen. Chia sẻ sự bối rối rằng timeline có vẻ được sắp từ vụ rò rỉ cũ nhất đến mới nhất, nhưng cách ghi ngày lại là thời điểm vụ rò rỉ được công khai chứ không phải thời điểm dữ liệu thực sự bị lộ. Gợi ý rằng để rõ ràng hơn, cả cách sắp xếp lẫn cách hiển thị nên đều dựa trên “ngày công bố”, còn bên trong mỗi thẻ thì hiển thị ngày rò rỉ thực tế theo định dạng chuẩn