1 điểm bởi GN⁺ 2023-12-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Have I Been Pwned (HIBP), được Troy Hunt công bố ngày 4/12/2013, khởi đầu là một dự án cá nhân để kiểm tra bằng email xem có bị rò rỉ hay không; 10 năm sau, nó đã trở thành hạ tầng bảo mật mà cá nhân, doanh nghiệp và chính phủ dựa vào
  • Khi đó rất khó kiếm một tên miền .com thông thường và lựa chọn này cũng xuất phát từ việc không nghĩ dự án sẽ tồn tại lâu dài, nhưng từ pwned nay đã gắn rất chặt với HIBP
  • Qua việc xuất hiện trên truyền thông, điều trần trước Quốc hội Mỹ, hợp tác với các cơ quan thực thi pháp luật như FBI và NCA của Anh, cũng như ra mắt Pwned Passwords, vai trò của HIBP đã vượt xa một trang tìm kiếm đơn thuần
  • Project Svalbard, dự án xem xét bán lại HIBP năm 2019, diễn ra trong bối cảnh áp lực cá nhân và vấn đề phụ thuộc vào dịch vụ, nhưng cuối cùng không thành; Hunt qua đó tái khẳng định rằng tính độc lập rất quan trọng với mình
  • Rò rỉ dữ liệu được dự đoán sẽ tiếp tục tăng; HIBP sẽ chuyển sang cách vận hành chính thức hơn, nhưng Hunt muốn tránh để nó phình thành một tổ chức lớn và gánh nặng mà ông không mong muốn

Từ dự án nhỏ thành hạ tầng 10 năm

  • Ngày 4/12/2013, Troy Hunt công bố dịch vụ bằng một tweet cho biết “Have I Been Pwned?” đã bắt đầu hoạt động
  • Ngày hôm sau, ông đăng blog giải thích cách giúp tìm kiếm nhanh 154 triệu bản ghi; các bài viết gắn thẻ HIBP đến bài kỷ niệm 10 năm đã đạt 185 bài
  • Bài hồi tưởng 10 năm đề cập đến cách xây dựng dịch vụ, các quyết định vận hành, nhiều sự cố xâm phạm dữ liệu, cùng một số trải nghiệm trước đó chưa được công khai

Vì sao là “Pwned”

  • Việc chọn tên chịu ảnh hưởng bởi thực tế khó kiếm tên miền .com với một tên tiếng Anh phổ thông, và khi đó cũng không kỳ vọng nhiều rằng dự án sẽ kéo dài
  • “pwned” dần gắn với HIBP gần như một từ đồng nghĩa; với nhiều người, đây là lần đầu họ gặp từ này trong ngữ cảnh “Have I Been...”
  • Trong các tài liệu trực tuyến giải thích nghĩa của “pwned”, HIBP do Hunt tạo năm 2013 cũng xuất hiện như một ví dụ
  • Vì tên thường bị phát âm sai hoặc gõ nhầm, Hunt đã sở hữu nhiều biến thể tên miền
    • haveibeenpaened.com
    • haveibeenpwnded.com
    • haveibeenporned.com
    • haveibeenprawned.com
    • haveibeenburned.com
    • haveigotpwned.com
    • haveibeenrekt.com
    • haveibeenfucked.com

Xuất hiện trên truyền thông và cú sốc lưu lượng

  • Mỗi khi rò rỉ dữ liệu trở thành tin tức chính thống, HIBP thường được nhắc đến như “nơi kiểm tra xem mình có bị ảnh hưởng hay không”
  • Việc xuất hiện trên truyền thông giúp tăng nhận diện, nhưng sau chương trình Martin Lewis Money Show ở Anh năm 2016, lượng truy cập tăng đến mức khiến dịch vụ ngoại tuyến
    • Từ trải nghiệm này, Hunt rút ra bài học về cách xử lý các đợt tăng lưu lượng lớn và triển khai biện pháp để chuyện tương tự không tái diễn
  • Năm 2018, Gizmodo xếp HIBP cùng Wikipedia, Google, Amazon và các trang khác vào danh sách “100 website đã định hình Internet”
  • Năm 2014, TIME chọn HIBP là một trong 50 website của năm
  • HIBP cũng xuất hiện trên nhiều cơ quan truyền thông lớn như The Wall Street Journal, The Standard, USA Today, Toronto Star, De Telegraaf, VG, Le Monde và Corriere della Sera

Điều trần trước Quốc hội Mỹ

  • Khoảng 6 năm trước, Hunt điều trần trước Quốc hội Mỹ về tác động của rò rỉ dữ liệu đối với việc xác minh danh tính
  • Vì đây là phiên điều trần công khai, video lời khai vẫn được lưu lại như hồ sơ
  • Trải nghiệm trả lời câu hỏi của các nghị sĩ trở thành một trong những khoảnh khắc đáng nhớ nhất trong sự nghiệp của Hunt
  • Bức ảnh khi đó hiện được treo trên bức tường bên ngoài văn phòng của ông, liên tục nhắc ông nhớ HIBP đã dẫn đến vị trí ấy như thế nào

Project Svalbard và thương vụ bán lại bất thành

  • Tháng 6/2019, Hunt công khai khả năng bán HIBP dưới tên Project Svalbard
  • Một trong những lý do lớn cho quyết định khi đó là stress; hơn một năm sau, ông tiết lộ một nguyên nhân quan trọng của áp lực ấy là việc ly hôn
  • Các vấn đề trong quan hệ tạo ra áp lực lớn, và Hunt nghĩ việc bán một dự án ông yêu thích nhưng ngày càng đòi hỏi nhiều hơn có thể là lối thoát
  • Project Svalbard trái lại dẫn đến tranh chấp pháp lý với vợ cũ, và giá trị lẽ ra có thể hiện thực hóa nếu bán được đã trở thành một phần của cuộc tranh chấp
  • Khi đang thảo luận với nhiều công ty công nghệ ở San Francisco về khả năng mua lại, một người có thể trở thành sếp mới hỏi ông “một ngày hoàn hảo ở văn phòng” sẽ như thế nào, khiến Hunt nhận ra tính độc lập quan trọng với mình đến mức nào
  • Sau 6 tháng, Project Svalbard kết thúc khi một giao dịch đã đạt được không thành
    • Không thể nói rõ tình tiết chính xác do NDA; cách diễn đạt công khai được dùng là “thay đổi trong môi trường kinh doanh phía người mua”
    • Nhìn lại, Hunt thấy mình đã mất nhiều thứ nhưng rất biết ơn kết quả cuối cùng

Hợp tác với FBI, NCA và các cơ quan thực thi pháp luật

  • Với Hunt của 10 năm trước, việc FBI công khai liên hệ với HIBP là điều ngoài dự đoán
  • FBI đang cung cấp dữ liệu cho HIBP; NCA của Anh và nhiều cơ quan thực thi pháp luật trên thế giới cũng cung cấp dữ liệu
  • Nhiều chính phủ quốc gia cũng đã công khai nói về việc sử dụng HIBP
  • Tháng 9/2023, ABC mô tả vai trò của HIBP và Hunt là “một dấu hiệu kỳ lạ của thời đại”, nhận định rằng “một người trên web” đã trở thành nhân vật trung tâm một cách kỳ lạ trong an ninh mạng toàn cầu
  • Mục đích của HIBP là “làm điều tốt sau khi điều xấu đã xảy ra”, cũng tương đồng với mục tiêu bảo vệ con người của các cơ quan thực thi pháp luật
  • Hunt 10 năm trước chưa hiểu rằng các cơ quan thực thi pháp luật thường làm việc cùng doanh nghiệp tư nhân để bảo vệ người dân, nhưng hiện nay ông có quan hệ hiệu quả với người của nhiều cơ quan

Sự tăng trưởng của Pwned Passwords

  • Ban đầu không có kế hoạch đưa mật khẩu vào HIBP, và Hunt cho rằng cần tránh tình huống mật khẩu xuất hiện cạnh tên người dùng
  • Tuy nhiên, ông đánh giá danh sách mật khẩu bị rò rỉ đã tách khỏi thông tin cá nhân có thể là một cách tận dụng dữ liệu xâm phạm cho mục đích tốt
  • Năm 2017, Pwned Passwords được ra mắt
  • Tháng 9/2023, Pwned Passwords ghi nhận 282 triệu yêu cầu trong một ngày, và tổng số yêu cầu trong 30 ngày vượt 6 tỷ
  • Theo thống kê mới nhất tại thời điểm hồi tưởng, dịch vụ đã xử lý 301,6 triệu yêu cầu trong một ngày của tuần đó, và 100.0000000000% số yêu cầu ấy được phục vụ từ cache của Cloudflare
  • Dịch vụ này miễn phí, không cần xác thực, cả mã nguồn và dữ liệu đều là mã nguồn mở, và FBI cung cấp dữ liệu
  • Hunt cho rằng trong các cuộc tấn công credential stuffing nhắm vào dịch vụ trực tuyến quy mô lớn, một phần đáng kể tài khoản bị chiếm đoạt đã dùng những mật khẩu lẽ ra có thể bị chặn

Nghịch lý của việc xử lý dữ liệu xâm phạm

  • HIBP mang một nghịch lý: vừa xử lý dữ liệu rò rỉ vốn là sản phẩm của tội phạm, vừa cố gắng phục vụ lợi ích công cộng
  • Một số người nói sẽ báo FBI vì HIBP nắm giữ dữ liệu bị đánh cắp, nhưng Hunt thực tế đã hợp tác với FBI
  • Cũng có chỉ trích rằng HIBP “xử lý dữ liệu khi chưa có sự đồng ý”, dựa trên luật bảo vệ dữ liệu cá nhân, đặc biệt là EU và GDPR
  • Hunt cho rằng không ai đồng ý để dữ liệu của mình bị đưa vào một vụ rò rỉ, và sự cố rò rỉ với việc HIBP lập chỉ mục để dữ liệu đó có thể tìm kiếm là hai cuộc thảo luận riêng biệt
  • Trong 10 năm, nhìn chung khiếu nại rất ít, số trường hợp mỗi năm có thể đếm trên đầu ngón tay một bàn
  • Trong 10 năm, chỉ có một khiếu nại chính thức thông qua cơ quan quản lý quyền riêng tư của chính phủ, và vụ việc kết thúc sau khi Hunt trả lời các câu hỏi

Con người và cơ cấu vận hành

  • Ban đầu HIBP là một dự án sở thích mà một mình Hunt bỏ thời gian vào
  • Công việc thời kỳ đầu gồm xây dựng dịch vụ, thu thập dữ liệu xâm phạm, xác minh, công bố, viết mô tả và tự chỉnh sửa hơn 700 logo
  • Hiện nay, khi HIBP đã trở thành một phần quan trọng của Internet mà nhiều cá nhân, doanh nghiệp và chính phủ dựa vào, vấn đề phụ thuộc vào một mình Hunt ngày càng lớn
  • Bối cảnh xem xét bán lại năm 2019 cũng có một phần là “cơ cấu chỉ phụ thuộc vào một mình Hunt”
  • Cũng có lựa chọn tuyển người và phát triển như một công ty thông thường, nhưng Hunt không thấy các trách nhiệm như hợp đồng lao động, đàm phán lương, đánh giá hiệu suất, nghỉ ốm và nghỉ phép là hấp dẫn
  • Vai trò của Charlotte

    • Đầu năm 2021, Charlotte, người khi đó sắp trở thành vợ ông, bắt đầu làm việc tại HIBP
    • Charlotte từng làm quản lý dự án cho hội nghị NDC có trụ sở tại Na Uy trong 8 năm, làm việc với lập trình viên, diễn giả, người tham dự, nhà tài trợ và khách doanh nghiệp
    • Dù không phụ trách kỹ thuật, cô có bằng liên quan đến PR và khởi nghiệp, đồng thời cũng quen thuộc với thế giới công nghệ mà HIBP thuộc về
    • Charlotte phụ trách onboarding thuê bao doanh nghiệp, ticket hỗ trợ cho API và thuê bao tên miền, cũng như công việc kế toán và thuế
  • Vai trò của Stefán Jökull Sigurðarson

    • Đầu năm 2023, Stefán Jökull Sigurðarson tham gia bán thời gian, phụ trách nhiều công việc phát triển như viết mã, dọn dẹp và migration
    • Stefán đã theo dõi dịch vụ từ khi HIBP ra mắt, và đầu năm 2018 đã phát triển một trong những tích hợp quy mô lớn đầu tiên của API PwnedPasswords v2 trong EVE
    • Anh xem HIBP là một phần trong hành trình sự nghiệp diễn thuyết công khai, đóng góp mã nguồn mở, vai trò MVP và đóng góp cho một Internet an toàn hơn
    • Hunt cho rằng điều quan trọng là với Stefán, HIBP không chỉ là một công việc mà còn là niềm đam mê

Những vụ xâm phạm đáng nhớ

  • Trong 10 năm, số vụ xâm phạm được đưa vào HIBP đã đạt 731 vụ
  • Ashley Madison

  • Collection #1

    • Đầu năm 2019, vụ này làm tăng mạnh stress của Hunt và cũng ảnh hưởng sâu sắc đến quyết định xem xét bán dịch vụ
    • Với 773 triệu bản ghi, đây là vụ xâm phạm lớn nhất trên HIBP tính đến thời điểm hồi tưởng
  • Rosebutt

    • Đây là ví dụ cho thấy ngay cả các vụ rò rỉ dữ liệu nghiêm trọng đôi khi cũng có thể tạo ra khoảnh khắc hài hước
  • Shit Express

    • Đây là vụ một trang cho phép gửi ẩn danh các mẩu phân bị xâm phạm, khiến tính ẩn danh bị lung lay
    • Sau đó Hunt viết rằng các tuyên bố về tính ẩn danh thường rất dễ gây hiểu lầm

Hướng đi phía trước

  • Ngày thường của Hunt gần giống với việc buổi sáng kiểm tra email và các sự kiện xảy ra qua đêm, rồi di chuyển theo những việc ngày hôm đó đòi hỏi
  • Cách vận hành này liên quan đến lý do ông không muốn HIBP phát triển thành một tổ chức có trách nhiệm lớn hơn
  • Đồng thời, HIBP đang dần trở nên chính thức hóa hơn
    • 3 năm trước, Hunt tự làm 100% mọi việc
    • 1 năm trước, ông tự làm toàn bộ công việc kỹ thuật
    • 6 tháng trước, chưa có hệ thống ticket hỗ trợ
  • Hunt muốn HIBP tồn tại lâu hơn bản thân mình, nhưng không muốn quá trình đó trở thành gánh nặng trói buộc ông
  • Ông cho rằng sẽ còn nhiều vụ xâm phạm hơn nữa, và gần đây cảm giác như ransomware đang tăng nhanh
  • Vẫn còn câu hỏi liệu những người có email, tài liệu và nhiều loại dữ liệu khác bị công khai qua ransomware có biết rằng mình đã bị lộ hay không
  • Việc lập chỉ mục các dữ liệu như vậy không đơn giản vì nhiều lý do, nhưng ông cho rằng nó ngày càng có vẻ là một công việc có giá trị

1 bình luận

 
GN⁺ 2023-12-05
Ý kiến trên Hacker News
  • Troy Hunt thật sự là một người rất đáng quý, và nếu là nhà phát triển ứng dụng web thì hầu như không có lý do gì để không triển khai phòng chống credential stuffing
    Tốt nhất có lẽ là xác thực hai yếu tố[1], nhưng đối chiếu với cơ sở dữ liệu mật khẩu đã băm của Hunt cũng là một lớp phòng vệ khá tốt mà không tạo thêm gánh nặng cho người dùng
    Tôi không có số liệu để chứng minh, nhưng tôi cho rằng phần lớn áp đảo các tài khoản bị xâm phạm là do credential stuffing hoặc tái sử dụng mật khẩu. Mỗi khi nghe nói các công ty lớn không làm bước kiểm tra này tôi đều thấy ngạc nhiên, trong khi cấu hình cũng đơn giản và có thể làm trong khoảng một ngày
    Nếu bạn là CTO trẻ hoặc kỹ sư webapp giai đoạn đầu, có thể sẽ có ngày bị ám ảnh khi điện thoại đổ chuông dồn dập lúc 1 giờ sáng, trang web đang bị tấn công, ban đầu tưởng là DDoS rồi nhận ra phần lớn lưu lượng đang dồn vào trang đăng nhập, và một phần trong số đó thực sự đăng nhập thành công. Sau đó bạn phải thức trắng đêm ứng phó rồi còn làm thông báo sự cố xâm phạm, thực sự rất khủng khiếp
    Cơ sở dữ liệu miễn phí của Troy Hunt có lẽ sẽ giúp giảm bớt nỗi đau đó, nên cứ triển khai đi

    1. https://cheatsheetseries.owasp.org/cheatsheets/Credential_St...
    2. Trường hợp như 23andMe. https://news.ycombinator.com/item?id=37794379
    • Khoảng 10 năm trước, tại một sự kiện nơi một nhân viên FBI đang thuyết trình, tôi nghe kể về một quản trị viên hệ thống đã lấy cơ sở dữ liệu mật khẩu đã băm của công ty, đối chiếu với các hash rò rỉ đã biết, rồi ép đặt lại mật khẩu và gửi email hướng dẫn cho những nhân viên dùng mật khẩu bị tái sử dụng, sau đó lại bị bắt
      Một nhân viên đã nổi giận, cho rằng hành động đó là xâm phạm quyền riêng tư, và tôi không nhớ ai là người khởi xướng vụ việc pháp lý, nhưng kết luận là nhân viên FBI và thẩm phán đều xem việc quản trị viên hệ thống truy cập các hash mật khẩu mà anh ta phụ trách là hành vi xâm phạm quyền riêng tư mang tính hình sự, dù mục đích là cải thiện bảo mật
      Nếu câu chuyện của nhân viên FBI không phải bịa ra, thì có vẻ thận trọng hơn nếu để bộ phận pháp lý rà soát trước khi kiểm tra xem hash mật khẩu của nhân viên có xuất hiện trong haveibeenpwned hay không
    • Ngoài xác thực hai yếu tố, áp dụng giới hạn tốc độ cho endpoint đăng nhập theo cả địa chỉ IP và tên người dùng là biện pháp phòng vệ vững chắc hơn nhiều trước kiểu tấn công này
      Ví dụ, nếu trong 1 phút gần nhất có 20 lần đăng nhập thất bại từ cùng một IP hoặc với cùng một tên người dùng, thì chặn IP hoặc tên người dùng đó trong 15 phút. Nhiều API gateway, K8s ingress v.v. hỗ trợ việc này rất dễ, và kể cả không có thì cũng có thể thêm bằng vài dòng code bằng cách lưu số lần đăng nhập gần đây vào Redis hoặc nơi tương tự
      Đối chiếu với cơ sở dữ liệu HIBP cũng là một lựa chọn tốt, nhưng để chặn kiểu tấn công này thì giới hạn tốc độ hiệu quả hơn nhiều
    • Tôi chưa hiểu rõ quy trình này. Nếu cơ sở dữ liệu chứa mật khẩu đã băm, thì làm sao biết được trang của tôi và cơ sở dữ liệu đó dùng cùng salt và thuật toán băm?
      Ví dụ, nếu Tumblr bị hack và mật khẩu hunter2 của tôi bị lộ, nhưng Tumblr dùng HMAC-MD5 đơn giản có salt còn trang của tôi thì tất nhiên dùng argon2 với salt khác, thì dù cùng một mật khẩu kết quả hash vẫn sẽ khác. Tôi không hiểu điều này giúp ích thế nào trong việc ngăn credential stuffing
    • Nếu bạn đang xây mới hệ thống đăng nhập/xác thực từ đầu, thì tốt hơn là đừng nhận mật khẩu rồi lưu vào cơ sở dữ liệu
      Hãy thiết lập social OAuth, SSO, email magic link và biến nó thành vấn đề của người khác
    • Tôi không hiểu vì sao người dùng phải cảm thấy có lỗi khi dùng mật khẩu 1234
      Trừ khi đó là một trang nhắm tới người dùng dễ tổn thương, còn không thì tôi cho rằng đó là trách nhiệm của người dùng. Như một bình luận khác đã nói, những người như vậy rất có thể sẽ “sửa” lỗi theo cách dễ nhất, kiểu 1234tênwebsite
      Tôi cho rằng bất kỳ giới hạn nào thêm vào ô nhập mật khẩu đều làm giảm entropy, và dù chỉ một chút cũng làm giảm mức độ an toàn của tất cả mọi người
  • Tôi nhớ trang này trước đây từng mang lại trải nghiệm rất tốt, nhưng giờ lại có cảm giác như một cỗ máy kiếm tiền với mức 169,50 USD/năm chỉ để xem 100 tài khoản bị lộ
    Tôi dùng địa chỉ email riêng cho từng website để phát hiện rò rỉ dữ liệu, và khi thử tra cứu kết quả cho một domain mà trước đây tôi đã xác minh quyền sở hữu, thì nhận được lỗi “cần gói đăng ký đủ lớn để tìm kiếm các domain có hơn 10 tài khoản bị lộ”
    Tệ hơn nữa là Troy còn đưa cả các bộ dữ liệu công khai vào mục “rò rỉ”, khiến hạn mức số tài khoản bị lộ bị thổi phồng một cách giả tạo. Ví dụ, có lần một tập hợp thông tin liên hệ công khai bị lấy từ GitHub cũng bị tính là rò rỉ, dù địa chỉ email của tôi vốn đã được công khai rõ ràng
    Với một dịch vụ chi phí thấp như thế này, tôi sẵn sàng trả 5–12 USD mỗi năm, nhưng mức giá hiện tại thì vô lý

    • Tôi cũng gặp chuyện tương tự và mong sẽ có một bảng giá riêng cho những người như chúng ta. Có lẽ đáng để thử hỏi xem sao
    • Chỉ cần tải cơ sở dữ liệu từ DarkNet về và chạy cục bộ thì khỏi phải trả tiền
      Nhược điểm là bạn phải tự quản lý cơ sở dữ liệu và cập nhật thường xuyên. Tôi đã thấy khá nhiều dịch vụ kiếm tiền kiểu này, bán quyền truy cập API vào cơ sở dữ liệu với thu phí
    • Việc tự vận hành domain email riêng, dùng địa chỉ khác nhau cho từng website, rồi còn quét xem domain cá nhân có bị lộ hay không là một cách dùng khá đặc thù
      Khó có thể nói trường hợp sử dụng cực kỳ cụ thể đó là con bò sữa tiền mặt đối với Troy Hunt
    • Tôi cũng dùng cùng cách đó và vẫn luôn thắc mắc vì sao đã lâu không nhận được cảnh báo rò rỉ
      Tôi không nhớ đã từng thấy thông báo nào về thay đổi này
    • Lại thêm một ví dụ của kiểu “mọi thứ đều là dịch vụ”
      Ban đầu nó là một dịch vụ tốt, nhưng khi lượng dùng tăng lên thì họ đẩy các tính năng ra sau bức tường trả phí và làm bản miễn phí tệ tới mức gần như vô dụng — một mô hình freemium rất tệ. Facebook có tệ thật nhưng cũng chưa đến mức này, và “Facebook miễn phí” cùng lắm chỉ bị theo dõi nhiều hơn chứ ít nhất vẫn giữ được tính năng như hồi 2010
  • Việc xuất hiện các biến thể như haveibeenburned.com, haveigotpwned.com, haveibeenrekt.com, và haveibeenfucked.com do ai đó đề xuất sau khi lộ ra rằng PornHub theo dõi nó, khá buồn cười như một tác dụng phụ của sự nổi tiếng trên truyền thông

    • Tôi luôn thích blog của PornHub: https://www.pornhub.com/insights/
    • Tên miền cuối cùng có thể thú vị như một kho lưu trữ revenge porn, nhưng việc phát tán là bất hợp pháp ở nhiều khu vực pháp lý
      Thay vào đó, có lẽ có thể tạo một cơ sở dữ liệu hash nhận diện khuôn mặt cho revenge porn, rồi tải lên hash tương tự của chính khuôn mặt mình để kiểm tra xem nó có ở đâu đó trên mạng hay không
    • Vài năm trước tôi có một cặp bạn mà người vợ mang thai, và họ thực sự có hơi xấu hổ vì việc “mọi người đều biết chúng tôi đã ‘làm chuyện đó’”
      Đó là một mức độ ngượng ngùng mà tôi chưa từng tưởng tượng tới
    • Đây là bằng chứng rằng quy tắc Internet có hiệu lực. Cái gì tồn tại thì đều có phiên bản khiêu dâm của nó
  • Tôi thực sự rất thích các bài viết giàu thông tin của Hunt
    Tôi nhớ đã đọc về cách dùng k-anonymity để đối chiếu các tệp pwned và mật khẩu mà không cần gửi dữ liệu cá nhân thật, và nhờ vậy tôi đã tìm hiểu khái niệm đó rồi áp dụng vào cả dự án ở chỗ làm
    Thỉnh thoảng tôi tự hỏi mình đã làm thế nào nếu không đọc những bài viết về việc kiểm tra mà không phải gửi dữ liệu cá nhân thật

    • k-anonymity đúng là một kỹ thuật cực kỳ thông minh, và tôi nhớ lần đầu đọc đã rất ấn tượng trước sự đơn giản và hiệu quả của nó
      Tôi cũng muốn nhắc đến Junade Ali, người mà Troy đề cập là người đề xuất [1]. Anh ấy giải thích chi tiết hơn trong bài viết liên quan [2]
      Không phải là Junade phát minh ra nó; có vẻ ban đầu nó thuộc về Pierangela Samarati, Latanya Sweeney và Tore Dalenius [3], nhưng bài blog của anh ấy là một lời giải thích rất tốt, diễn giải nó thành những khái niệm quen thuộc với các lập trình viên
      [1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
      [2] https://blog.cloudflare.com/validating-leaked-passwords-with...
      [3] https://en.wikipedia.org/wiki/K-anonymity
  • Những kẻ lừa đảo tống tiền đang dùng cơ sở dữ liệu mật khẩu pwned để tạo ra các email lừa đảo khá thuyết phục
    Kiểu như: “Tôi đã cài công cụ truy cập từ xa vào hệ thống của bạn và theo dõi qua webcam. Bằng chứng bị hack là mật khẩu này. Hãy gửi số BTC trị giá 1800 đô la đến địa chỉ này và đừng báo cảnh sát. Lần sau hãy dùng trình quản lý mật khẩu.” Tôi tự hỏi liệu có ai thực sự mắc bẫy trò lừa này không
    Có lẽ phần lớn sẽ bị bộ lọc spam chặn lại, và tôi chỉ thấy chúng khi vượt qua được bộ lọc SPF/DKIM nên đã được huấn luyện thêm. Trông khá tinh vi
    Dù sao tôi vẫn biết ơn dịch vụ này và cũng thích đọc các bài của Troy Hunt. HIBP rất tuyệt

    • Một người trong gia đình tôi đã gọi điện vì lo không biết email đó có thật không
      Nó không chỉ có mật khẩu cũ mà còn có đầy đủ địa chỉ gửi thư và 4 số cuối của thẻ tín dụng, và đúng là có người tin những thứ đó
    • Tra cứu Pwned Passwords chỉ trả về số lần bị lộ, không trả về hash hay mật khẩu dạng rõ
      Chỉ riêng chức năng này thì không thể thực hiện kiểu tấn công đó
    • Tôi không biết có ai thực sự bị lừa hay không, nhưng tôi đã nghe chuyện người dùng hoảng hốt chạy đến đội IT để nhờ xác minh
      Tôi cũng đã nhận một hai email kiểu này, và hoàn toàn không đoán ra nổi mình đã dùng cái mật khẩu khá yếu đó ở trang nào
    • Có lần tôi nhận được một email chứa mật khẩu của mình ở dạng rõ và thấy khá khó chịu
      Tôi tìm nhanh thì thấy đó không phải mật khẩu tôi dùng ở nơi nào quan trọng nên bỏ qua, nhưng dù biết đó là mật khẩu cũ tôi vẫn thấy gai người
      Nếu không dùng trình quản lý mật khẩu, chắc tôi đã không thể xác nhận ngay mật khẩu đó từng được dùng ở đâu mà phải vắt óc nhớ lại, và thật khó tưởng tượng cảm giác đó
  • Tác động của HaveIBeenPwned đến nhận thức của người dùng là điều đáng chú ý
    Trong khi đó, SpyCloud có bộ dữ liệu lớn hơn 30 lần và làm việc trực tiếp với các doanh nghiệp để thực sự giảm việc tái sử dụng mật khẩu, nhưng có cảm giác chưa được công nhận xứng đáng
    Nếu bạn từng bị yêu cầu đặt lại mật khẩu khi đăng nhập vào một website lớn, hoặc từng nhận email bảo đổi mật khẩu vì nó đã được dùng ở nhiều nơi, rất có thể phía sau là SpyCloud

    • Có thể đó không phải chủ ý, nhưng cách diễn đạt đó nghe như thể HIBP không trực tiếp hợp tác với doanh nghiệp để giảm tái sử dụng mật khẩu
      Thực tế là có. Ví dụ như hợp tác với 1Password và các trình quản lý mật khẩu khác, Firefox, FBI, cùng chính phủ Anh và Úc
    • So sánh một dịch vụ miễn phí giúp hàng triệu người với một công ty yêu cầu đăng ký cho bất kỳ cách sử dụng nào không phải là một phép so sánh ngang hàng
      Cái sau hầu như không hữu ích gì với đa số mọi người
    • Tôi cho rằng số người thực sự giảm được việc tái sử dụng mật khẩu nhờ tích hợp dữ liệu mật khẩu pwned miễn phí của Troy còn nhiều hơn số khách hàng của SpyCloud
  • Nếu bạn quan tâm đến quyền riêng tư, đây là cách xóa thông tin của mình khỏi tìm kiếm công khai
    https://haveibeenpwned.com/OptOut

    • Nếu email của tôi vẫn còn trong các nơi như Collection #1 hay Anti Public Combo List thì việc loại khỏi HIBP có vẻ không mấy tác dụng
      Những người muốn làm điều xấu với email có lẽ sẽ tải toàn bộ danh sách gốc xuống thay vì cào dữ liệu từ một trang tổng hợp
    • Tôi tự hỏi liệu họ có hỗ trợ loại trừ ở cấp độ domain không
    • Tuy nhiên, bạn phải vượt qua Google ReCaptcha, nên những người nhạy cảm với quyền riêng tư sẽ không thích điều đó
      Nhân tiện, ở đó có ghi rằng “quản trị viên của domain mà địa chỉ email của bạn thuộc về vẫn có thể nhìn thấy bạn trong tìm kiếm theo domain”
  • Tự hỏi trong 10 năm qua đã có bao nhiêu nạn nhân bị theo dõi biết rằng thủ phạm đã dùng HaveIBeenPwned như một công cụ hướng dẫn dễ dàng để tìm ra và xâm phạm tài khoản cũng như đời tư của họ
    Tất nhiên, lập trường của trang là nạn nhân nên đăng ký trước và tắt việc bị hiển thị trong tìm kiếm trước khi kẻ xấu dùng dịch vụ
    Tức là việc gây sốc cho người khác bằng thông báo “thông tin của bạn đang ở ngoài kia!” ngay khi nhập địa chỉ còn quan trọng hơn sự an toàn của người dùng, thay vì chỉ hiển thị sau khi xác minh email

    • Nếu thêm bước xác minh email thì chi phí vận hành dịch vụ có thể tăng lên rất nhiều và khó bền vững
      Nếu đã có địa chỉ email của ai đó, liệu có thật sự cần HIBP để biết địa chỉ đó được dùng ở đâu không? Chỉ với Google thôi cũng đã ra rất nhiều kết quả rồi mà?
    • Đồng ý. Nó còn tệ hơn vì cung cấp 90% thông tin mà kẻ tấn công cần, trong khi lại không cho nạn nhân biết dữ liệu nào đã bị lộ
      Tôi muốn xem hash để có thể biết mật khẩu nào đã bị xâm phạm
    • Bạn có thể giải thích thêm HIBP có thể bị lạm dụng như thế nào không? Chẳng phải nó chỉ là kiểm tra xem email có nằm trong danh sách bị lộ hay không sao?
  • “Lái jet ski và làm bất cứ điều gì tôi muốn” — vậy Troy Hunt là biến thể Mobius à?

  • Tò mò không biết ông ấy có từng viết nhiều về chi tiết cụ thể của vụ ly hôn không
    Có phải hiểu là mọi thứ trở nên dài dòng và tốn kém do quá trình chia 50% tài sản và sắp xếp ai sở hữu những gì không?