Bảo mật

Bằng chứng cho thấy trình duyệt của bạn không phải là két an toàn.

Chrome và Firefox sẽ lưu mật khẩu của bạn — và sau đó giao chúng cho bất kỳ chương trình nào đang chạy dưới danh nghĩa của bạn. Đó không phải là lỗi. Đó là do thiết kế. Đây là bằng chứng: một bản bằng ngôn ngữ dễ hiểu, một bản bằng mã.

Phiên bản ngôn ngữ dễ hiểu

"Trình quản lý mật khẩu" của trình duyệt chỉ được bảo vệ bởi một ổ khóa duy nhất: thông tin đăng nhập máy tính của bạn. Khi bạn đã đăng nhập vào máy tính xách tay của mình, trình duyệt có thể đọc mọi mật khẩu đã lưu ngay lập tức — vì vậy bất kỳ chương trình nào khác đang chạy trên tài khoản của bạn cũng có thể làm điều đó.

Một tệp tải xuống độc hại. Một trò chơi trên trình duyệt đáng ngờ. Một gói nhiễm độc trong một dự án bạn đã sao chép. Ngay khi nó chạy — khi bạn đang đăng nhập, như bạn vẫn luôn làm — nó sẽ đọc mọi mật khẩu mà trình duyệt của bạn đã lưu, chỉ trong thời gian mở một tệp. Không có mật khẩu tổng nào để bẻ khóa, vì không có gì để bẻ khóa: trình duyệt được tạo ra để tự động mở khóa cho bạn, và phần mềm độc hại chỉ cần đưa ra yêu cầu dưới danh nghĩa "bạn".

Đây không phải là lý thuyết suông. Đây là cách phổ biến nhất khiến người dùng thông thường bị mất tài khoản. Phần mềm độc hại thậm chí còn có một thuật ngữ ngành nhàm chán — "info-stealer" — vì nó đã quá phổ biến. Mật khẩu của bạn, thẻ thanh toán đã lưu của bạn, cookie phiên của bạn: bị sao chép và biến mất trước khi bạn nhận ra.

Giải pháp rất đơn giản: mật khẩu của bạn nên được khóa bằng thứ mà phần còn lại của máy tính không thể truy cập — và chúng không nên được lưu trữ trên máy tính dưới bất kỳ hình thức nào.

Phiên bản kèm bằng chứng

Đừng chỉ tin lời chúng tôi. Chromium và Firefox là mã nguồn mở, và luồng đọc được tài liệu hóa, chuẩn hóa và rất ngắn. Đây chính xác là nơi mật khẩu được lưu trữ và cách chúng được lấy ra.

Chrome (và mọi trình duyệt Chromium)

Chrome lưu trữ thông tin đăng nhập trong cơ sở dữ liệu SQLite — Login Data, bảng logins, cột password_value — được mã hóa bằng AES-256-GCM. Khóa AES nằm trong Local State, được "bảo vệ" bởi hệ điều hành: DPAPI trên Windows, Keychain đăng nhập trên macOS, gnome-keyring/kwallet (hoặc văn bản thuần) trên Linux.

Hãy tự kiểm tra — mã nguồn mở. Tìm kiếm trong mã nguồn Chromium hằng số đánh dấu khóa được bọc: kDPAPIKeyPrefix trong os_crypt. Khóa được bọc DPAPI, đánh dấu và lưu trữ — sau đó được giải bọc bằng một lệnh gọi duy nhất không hề bảo vệ được gì trước bạn:

const char kDPAPIKeyPrefix[] = "DPAPI";

CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
                   /*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);

Không có bí mật phụ, không mật khẩu, không lời nhắc. CryptUnprotectData trả lại khóa cho bất kỳ quy trình nào đang chạy trong phiên của bạn — đây chính xác là mô hình mối đe dọa mà DPAPI ghi lại: nếu nó chạy dưới danh nghĩa của bạn, thì nó bạn. Toàn bộ công việc của kẻ tấn công chỉ gồm ba dòng: đọc khóa từ Local State, giải bọc nó, giải mã AES-GCM mọi hàng trong Login Data. Mã độc đánh cắp thông tin đã làm chính xác điều này trong nhiều năm.

"Mã hóa trên thiết bị" cũng không cứu được bạn

Câu trả lời của Google là một mã PIN gồm 6 chữ số để mã hóa két an toàn được đồng bộ hóa của bạn. Vào tháng 5 năm 2026, các nhà nghiên cứu tại Phishu đã chỉ ra sự yếu kém của cơ chế này. Một lần đăng nhập Google giả mạo thuyết phục — tấn công lừa đảo trung gian — sẽ chiếm quyền phiên và mã PIN đó, và mã PIN chính là khóa chính cho mọi mật khẩu và passkey trong tài khoản được đồng bộ hóa. Với nó, kẻ tấn công sẽ thêm thiết bị của họ vào "miền bảo mật" Google của bạn và toàn bộ két an toàn sẽ được đồng bộ hóa trực tiếp với họ — chiếm quyền kiểm soát hoàn toàn chỉ trong một bước.

Lỗ hổng thiết kế: Google cho phép thêm một thiết bị chỉ bằng mã PIN 6 chữ số, mà không cần sự chấp thuận từ một thiết bị bạn đã sở hữu.

Firefox

Firefox lưu trữ thông tin đăng nhập trong logins.json và khóa trong key4.db, được giải mã bởi "Secret Decoder Ring" của NSS — cũng là mã nguồn mở: security/nss/lib/pk11wrap/pk11sdr.c. Nếu bạn đặt Mật khẩu chính, khóa sẽ được niêm phong bằng mật khẩu đó.

Theo mặc định, bạn chưa đặt mật khẩu này — vì vậy khóa được niêm phong bằng chuỗi trống, và một giá trị "password-check" đã lưu trữ xác nhận rằng mật khẩu trống giải mã nó. Sao chép hai tệp ra khỏi thư mục profile của bạn (key4.db + logins.json), chạy NSS hoặc firepwd.py mã nguồn mở với chúng, và chúng sẽ giải mã. Một ổ khóa mà chìa khóa bị dán ngay trên cửa không phải là ổ khóa.

The common thread

Mọi kho lưu trữ mật khẩu trình duyệt đều có cùng một cơ chế: bí mật nằm ngay trên máy bạn đang làm việc, được mở khóa bởi phiên làm việc hiện tại của bạn. Mã hóa mà phần còn lại của máy tính của bạn có thể giải mã không bảo vệ bạn khỏi mối đe dọa thực sự chiếm đoạt tài khoản — mã độc đang chạy dưới danh nghĩa của bạn.

Tại sao Clavitor không thể bị đọc theo cách này

Clavitor không lưu trữ két an toàn của bạn trên máy tính. Không có Login Data, không có key4.db, không có khóa trong Local State — không có gì trên ổ đĩa để một quy trình đang chạy dưới danh nghĩa của bạn có thể trích xuất.

Khóa giải mã không được niêm phong bằng thông tin đăng nhập hệ điều hành của bạn. Nó được tạo ra từ thao tác chạm phần cứng — Touch ID, Face ID, hoặc YubiKey — được tính toán trong trình duyệt, sử dụng cho một yêu cầu duy nhất, sau đó bị loại bỏ. Thông tin xác thực được truy xuất qua một API có phạm vi giới hạn chính xác khi bạn yêu cầu và không bao giờ được lưu vào bộ nhớ đệm. Phần mềm độc hại chạy dưới danh nghĩa của bạn sẽ chỉ tìm thấy một kho trống.

Đó là sự khác biệt giữa "mã hóa trên thiết bị của bạn" và "không lưu trữ trên thiết bị của bạn chút nào".

Ngừng giao phó mật khẩu của bạn cho trình duyệt.

Tiện ích mở rộng Clavitor tự động điền như trình duyệt của bạn — và lưu trữ két an toàn ở nơi máy tính của bạn không thể đọc được.