2 tỷ địa chỉ email đã bị lộ và đều được lập chỉ mục trên Have I Been Pwned

 (troyhunt.com)
3 điểm bởi GN⁺ 2025-11-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một tập dữ liệu khổng lồ chứa 1.957.476.021 địa chỉ email duy nhất và 1,3 tỷ mật khẩu đã được công khai và mới được bổ sung vào Have I Been Pwned (HIBP)
  • Trong số này, 625 triệu mật khẩu chưa từng được phát hiện trước đây, khiến đây trở thành bộ dữ liệu lớn nhất mà HIBP từng xử lý
  • Dữ liệu được thu thập từ nền tảng tình báo mối đe dọa của Synthient, bao gồm dữ liệu credential stuffing với các cặp email-mật khẩu bị rò rỉ từ nhiều vụ xâm phạm khác nhau
  • Để xác minh tính xác thực của dữ liệu, HIBP đã trực tiếp yêu cầu người đăng ký kiểm tra, và một phần trong đó vẫn chứa mật khẩu đang được sử dụng thực tế
  • Lần lập chỉ mục này không phải là vụ rò rỉ Gmail, mà là kết quả thu thập thông tin xác thực từ các nạn nhân bị nhiễm mã độc; người dùng có thể kiểm tra mức độ lộ lọt qua HIBP hoặc Pwned Passwords

Tổng quan dữ liệu

  • Tập dữ liệu bao gồm 1.957.476.021 địa chỉ email duy nhất và 1,3 tỷ mật khẩu
    • Trong đó 625 triệu mật khẩu là các mục HIBP phát hiện lần đầu
    • Đây là bộ dữ liệu lớn nhất mà HIBP từng xử lý cho đến nay, lớn hơn khoảng 3 lần so với vụ rò rỉ lớn nhất trước đó
  • Dữ liệu là một phần trong nguồn tình báo mối đe dọa do Synthient thu thập, gồm các danh sách credential stuffing
    • Dữ liệu credential stuffing được tạo ra bằng cách tái sử dụng các cặp email-mật khẩu bị lộ từ nhiều vụ xâm phạm khác nhau
    • Do thói quen dùng cùng một mật khẩu trên nhiều trang, một lần rò rỉ có thể dẫn đến việc tài khoản ở các dịch vụ khác cũng bị xâm phạm

Quy trình xác minh dữ liệu

  • Việc xác minh bắt đầu từ địa chỉ email cá nhân của tác giả, và một số mật khẩu cũ thực sự khớp
    • Những mật khẩu khác thì không quen thuộc, và một số còn chứa các giá trị bất thường như dạng địa chỉ IP
  • HIBP cũng yêu cầu những người đăng ký xác minh để thu thập thêm nhiều trường hợp
    • Một người dùng cho biết cả mật khẩu cũ lẫn mật khẩu gần đây đều xuất hiện và đã lập tức đổi mật khẩu
    • Một người dùng khác phát hiện có cả mật khẩu đã dùng từ 10 đến 20 năm trước
    • Một số người phản hồi cho biết các mật khẩu vẫn đang dùng trên tài khoản hoạt động cũng đã bị lộ
  • Kết quả xác minh cho thấy dữ liệu chứa lẫn cả thông tin cũ và mật khẩu đang còn được sử dụng
    • Một số mục là mật khẩu được tạo tự động hoặc đã quá cũ nên người dùng không còn nhớ

Tính năng tra cứu Pwned Passwords

  • Dịch vụ Pwned Passwords của HIBP lưu trữ riêng địa chỉ email và mật khẩu
    • Đây là biện pháp nhằm đảm bảo bảo mật và quyền riêng tư, tránh rủi ro lộ các cặp email-mật khẩu
  • Người dùng có thể kiểm tra mật khẩu của mình có bị lộ hay không bằng các cách sau
    1. Dùng trang tra cứu Pwned Passwords
    2. Tra cứu bằng mã thông qua k-anonymity API
    3. Kiểm tra tự động bằng tính năng 1Password Watchtower
  • Mọi tổ hợp PIN 4 chữ số đều đã từng bị lộ, và cũng đã có tài liệu trực quan hóa mẫu sử dụng PIN dựa trên dữ liệu HIBP

Không phải rò rỉ Gmail

  • Sự việc lần này không liên quan đến lỗ hổng bảo mật của Gmail, mà là dữ liệu thông tin xác thực của nạn nhân bị thu thập do nhiễm mã độc
  • Toàn bộ dữ liệu chứa 32 triệu tên miền email, trong đó gmail.com chiếm 394 triệu
    • Địa chỉ Gmail chỉ chiếm khoảng 20% tổng số, còn 80% còn lại thuộc các tên miền khác
    • Không liên quan đến lỗi bảo mật của Google

Quy trình xử lý kỹ thuật

  • Bộ dữ liệu lần này lớn hơn khoảng 3 lần so với vụ rò rỉ lớn nhất trước đó, khiến quá trình xử lý rất phức tạp
    • HIBP đã xử lý dữ liệu trong khoảng 2 tuần trên môi trường Azure SQL Hyperscale (80 lõi)
    • Trong quá trình tạo băm SHA1 cho địa chỉ email, việc cập nhật hàng loạt bị lỗi nên đã chuyển sang xử lý theo lô 1 triệu bản ghi
  • Trong 5,9 triệu người đăng ký, có 2,9 triệu người xuất hiện trong bộ dữ liệu lần này
    • Để tránh bộ lọc spam và giới hạn máy chủ khi gửi email hàng loạt, hệ thống đã áp dụng chiến lược gửi tăng dần
    • Lượng gửi được điều chỉnh với tốc độ tăng 1,015 lần mỗi giờ, tương đương khoảng 45% mỗi ngày
    • Thiết lập DKIM, DMARC, SPF và sử dụng IP chuyên dụng để duy trì độ tin cậy
  • Kích thước phản hồi API của Pwned Passwords tăng từ trung bình 26KB lên 40KB
    • Nguyên nhân là kích thước phạm vi băm đã tăng khoảng 50%, và hiệu quả vẫn được duy trì nhờ nén brotli

Kết luận và khuyến nghị

  • Bộ dữ liệu lần này có thể được tìm thấy trên HIBP với tên “Synthient Credential Stuffing Threat Data”
    • Đây là tập dữ liệu tách biệt với dữ liệu Synthient trước đó, dù có một phần trùng lặp
  • HIBP đã xác minh tính toàn vẹn của dữ liệu và cung cấp tính năng tra cứu tập trung vào bảo vệ quyền riêng tư
  • Các biện pháp bảo mật được khuyến nghị cho người dùng
    • Sử dụng trình quản lý mật khẩu
    • Tạo mật khẩu mạnh và duy nhất
    • Dùng passkey và bật xác thực đa yếu tố (MFA)
  • HIBP cho biết đây là một dự án rất tốn thời gian và chi phí, đồng thời kêu gọi người dùng tập trung cải thiện thói quen bảo mật thay vì yêu cầu truy cập vào dữ liệu

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-07
Ý kiến trên Hacker News

  • Đã có quá nhiều vụ rò rỉ dữ liệu từ trước đến nay. Có cảm giác như địa chỉ, SSN, số điện thoại, email và mọi thông tin khác của tôi đều đã lộ ra nhiều lần
    Tôi đã nhận thông báo rò rỉ từ trường đại học, các trang tìm việc, mạng xã hội, và ngoài ra có lẽ thông tin của tôi còn đang lưu hành qua cả hoạt động phân tích dữ liệu lớn hợp pháp
    Giờ tôi lưu và quản lý mật khẩu mạnh trong Bitwarden, nhưng có vẻ các tài khoản cũ tôi từng dùng vẫn còn rủi ro
    Thành thật mà nói giờ tôi cũng không biết còn có thể làm gì. Thật tiếc là thông tin của tôi đã ở ngoài kia rồi

    • Tôi dùng bí danh email khác nhau cho từng tài khoản và dùng trình quản lý mật khẩu
      Lúc rảnh tôi đang dọn dẹp các tài khoản cũ. Nhờ vậy tôi có thể nhận ra ngay nguồn spam hay nguồn rò rỉ qua địa chỉ email
      Dùng lọc Sieve thì còn phân loại tinh vi hơn nhiều. Nếu dùng cả envelope to và header to thì có thể lọc chính xác cả mail BCC hoặc mail bí danh
      Tài liệu liên quan: RFC5228 Sieve Filtering
      Trước đây tôi còn từng khôi phục lại một tài khoản đã quên nhờ email spam có chứa mật khẩu cũ của mình
    • Bitwarden đúng là đỉnh. Cá nhân tôi đang giới thiệu cho mọi người xung quanh, nhưng phản ứng khá hờ hững
      Vợ tôi thì nói việc bảo vệ thông tin trực tuyến đã là một trận chiến thua cuộc rồi. Có lẽ cô ấy cũng đúng
    • Địa chỉ phần lớn là hồ sơ công khai. Tìm trên những trang như fastpeoplesearch.com là ra ngay
      Số điện thoại trước đây cũng đều có trong danh bạ điện thoại. Tôi vẫn thấy nó giống thông tin công khai
    • Tôi cũng ở tình cảnh tương tự. Điều quan trọng là phải đóng băng tín dụng ở 3 hãng chấm điểm tín dụng lớn của Mỹ
      Trước đây từng có người mở dịch vụ truyền hình cáp bằng thông tin của tôi, và tôi đã rất khổ sở mới xóa được nó khỏi hồ sơ tín dụng
    • Tôi đang trong quân ngũ thì Trung Quốc còn lấy cả hồ sơ DNA của tôi. Giờ thì tôi mặc kệ rồi

  • Có vẻ Troy giờ sẽ tiết kiệm được kha khá dung lượng DB
    Kiểu như chỉ cần

    def email_compromised(email):
    return True

    là đủ, vì cảm giác email nào cũng đã bị lộ rồi

    • Không hẳn vậy. Hai email chính của tôi đến giờ vẫn hiện là sạch
      Còn mấy email linh tinh thì lại có tới 9 lần bị lộ

  • Có vẻ dữ liệu lần này bao gồm cả thông tin rò rỉ chưa được công bố của Spotify
    Đầu năm 2020, tài khoản Spotify của tôi dùng mật khẩu yếu từng bị đăng nhập từ một IP ở Mỹ
    Vài tiếng sau Spotify tự động gửi yêu cầu đặt lại mật khẩu, nhưng chưa từng có thông báo rò rỉ chính thức nào
    Giờ email đó cuối cùng cũng xuất hiện trên HIBP

    • Một công ty lớn như Spotify thì đáng ra phải báo cáo chính thức vụ rò rỉ như vậy

  • Tôi rất nể công việc của Troy Hunt, nhưng khi tra email của mình trên Have I Been Pwned thì không có cách hành động thực tế nào cả
    Trang này chỉ hiện thông điệp kiểu “hãy cẩn thận vì có rủi ro và quản lý mật khẩu cho tốt”
    Việc đổi toàn bộ hơn 500 mật khẩu là bất khả thi trong thực tế. Cuối cùng vẫn phải dựa vào các trình quản lý mật khẩu như Bitwarden, 1Password, Chrome

    • Mỗi trang phải dùng một mật khẩu ngẫu nhiên riêng biệt
      Trước đây tôi cũng từng tái sử dụng cùng một mật khẩu rồi bị chiếm toàn bộ tài khoản
      Giờ tôi chỉ nhớ mật khẩu chính của trình quản lý mật khẩu, Gmail, và mật khẩu mã hóa ổ đĩa; còn lại đều do trình quản lý tạo
      Ở nơi nào có thể thì tôi cũng bật 2FA(U2F/WebAuthn)
    • Đúng vậy. Cuối cùng thì trình quản lý mật khẩu mới là cốt lõi
    • Trên trang HIBP Passwords, bạn có thể nhập trực tiếp mật khẩu để kiểm tra an toàn xem nó đã bị lộ chưa
      1Password cũng hoạt động theo cách tương tự, và không lưu tên tài khoản nên không tạo ra rủi ro rò rỉ mới
    • Bộ dữ liệu lần này là dữ liệu tổng hợp từ nhiều vụ rò rỉ nên không thể biết nguồn gốc
    • Trước đây tôi từng nhận cảnh báo HIBP và lập tức đặt lại mật khẩu cho người dùng
      Nhưng đa phần đều là mật khẩu từ các vụ rò rỉ cũ, nên tôi cố tránh các hành động không cần thiết

  • Vì dùng nhiều địa chỉ email tùy chỉnh, muốn kiểm tra trên HIBP thì tôi phải trả tiền đăng ký
    Tôi đang vận hành hàng trăm email nên khá bất tiện. Dù vậy, dùng địa chỉ riêng cho từng trang vẫn rất đáng giá

    • Trước đây tính năng tìm kiếm tên miền từng miễn phí. Tôi đăng ký từ năm 2017 và đã nhận cảnh báo rò rỉ vào năm 2020, 2022
    • Thực ra nếu dùng email bí danh thì khi bị lộ bạn sẽ biết ngay. Chỉ với email thôi thì cũng khó mạo danh được ai
    • Tôi cũng giống vậy. Tôi theo dõi toàn bộ email trong trình quản lý mật khẩu, nhưng kiểm tra từng cái một trên HIBP thì rất phiền
    • Thực tế nhất là cứ giả định mọi email đều đã lộ rồi. Email không phải bí mật
    • Cuối cùng thì mật khẩu mới là bí mật thật sự. Chỉ cần giữ mật khẩu mạnh là ổn

  • Trước đây email cũ của tôi bị lộ trong vụ Facebook, rồi có người đăng ký lại tên miền đó và thử chiếm tài khoản
    May mà 2FA và cảnh báo bảo mật của Facebook đã chặn được
    Những địa chỉ email không còn dùng nữa thì nhất định phải xóa khỏi tài khoản

    • Nếu dùng tên miền riêng làm email thì sẽ có chi phí duy trì suốt đời. Nếu để mất tên miền, người khác có thể mua lại và thử khôi phục tài khoản
      Từ khi iCloud hay Gmail cho phép kết nối tên miền tùy chỉnh dễ dàng hơn, rủi ro kiểu này càng lớn
    • Thật ngạc nhiên là họ lại làm tới mức đó chỉ để nhắm vào một tài khoản
    • Tôi thấy lạ là người đó lại chịu bỏ tiền mua tên miền để thử. Tôi đâu phải người nổi tiếng

  • Đoạn nói rằng họ chạy Azure SQL Hyperscale với 80 lõi trong 2 tuần khá thú vị
    Chỉ để quản lý email và mật khẩu mà dùng SQL có vẻ là một lựa chọn quá mức cần thiết.
    Dù là 15 tỷ bản ghi thì cỡ 600GB có lẽ cũng xử lý được trên một máy chủ bình thường

    • Thực ra vấn đề là cập nhật 1,9 tỷ hash SHA1
      Cập nhật tại chỗ quá chậm nên họ tạo bảng riêng, và khi gửi email cảnh báo thì còn vướng cả giới hạn của nhà cung cấp email
    • Tôi cũng nghĩ vậy. Có lẽ Troy dùng Azure nhờ mối quan hệ với Microsoft
      Danh xưng “Microsoft Regional Director and MVP” nghe khá dễ gây nhầm lẫn
    • Azure SQL chắc chắn là lựa chọn sai. Nếu chỉ tra cứu hash thì cấu trúc dựa trên file nhị phân sẽ hiệu quả hơn nhiều
      Chỉ cần tạo một file 20GB chứa các hash SHA1 đã sắp xếp, rồi dùng binary search hoặc chỉ mục dựa trên phân bố hash là có thể tra cứu với 1 lần I/O
      Chia thành 65.536 chunk rồi sắp xếp thì cũng giải quyết được vấn đề bộ nhớ
      Kiểu cấu trúc này có thể vận hành trên Blob Storage với chi phí rẻ hơn Azure SQL khoảng 50 lần

  • Có vẻ dữ liệu HIBP có thời hạn hết hiệu lực nào đó. Trước đây email của tôi có trong vụ rò rỉ Dropbox, nhưng giờ bản ghi đã biến mất
    Trang vụ rò rỉ Dropbox

  • Tôi đang phân vân Bitwarden / 1Password / Proton Pass thì cái nào tốt hơn
    Proton Pass thì còn hơi sớm để tin tưởng, và tôi cũng nghĩ đến câu “đừng bỏ tất cả vào một giỏ”
    Tôi chọn Bitwarden vì nó là mã nguồn mở, và kỳ vọng rằng với tệp người dùng miễn phí lớn, vấn đề sẽ sớm bị lộ ra và được xử lý

    • Tôi đang dùng 1Password và thấy UI cùng tính năng quản trị doanh nghiệp tiện hơn nhiều
      Nếu dùng tài khoản doanh nghiệp thì còn được miễn phí tài khoản gia đình, đó cũng là ưu điểm
      Tuy vậy, triết lý mã nguồn mở của Bitwarden cũng hoàn toàn đáng để cân nhắc

  • Có lẽ tiêu đề của bài này nên là “1,3 tỷ mật khẩu đã bị lộ” thì chính xác hơn
    Con số nhỏ hơn một chút nhưng ý nghĩa lại lớn hơn nhiều

    • Số mật khẩu thực tế có lẽ còn ít hơn nữa 😉