- Sau nhiều năm tự self-hosting để sử dụng, Bitwarden đã trở thành một lựa chọn khó còn có thể khuyến nghị do máy chủ chính thức nặng nề, định hướng mã nguồn mở ngày càng thiếu minh bạch, chất lượng client thấp và các vấn đề bảo mật lặp đi lặp lại
- Trong khi Bitwarden server chính thức là một cấu hình nặng xoay quanh backend C# và MSSQL Express, thì máy chủ tương thích không chính thức dựa trên Rust Vaultwarden đơn giản và nhẹ hơn, nên thường được ưa chuộng trong các triển khai quy mô nhỏ và trung bình
- Giấy phép hạn chế của
@bitwarden/sdk-internal được đưa vào client năm 2024 đã được cấp phép lại theo GPLv3 sau phản ứng dữ dội, nhưng vẫn làm dấy lên lo ngại rằng dự án đang vận hành theo hướng lấy thuê bao SaaS làm trung tâm hơn là phần mềm miễn phí và mã nguồn mở
- Trên các client của Bitwarden đã tích lũy nhiều vấn đề như lỗi nhập kho dữ liệu, thiếu khả năng chuyển mục giữa kho
organization và kho cá nhân, giải pháp lách để xuất JSON dạng văn bản thuần, mất quyền truy cập kho do tự động cập nhật, cùng UI chậm và trải nghiệm tự động điền bất tiện
- Thay vì giao toàn bộ thông tin xác thực cho một kho duy nhất, việc tách riêng dự án chuyên môn/khách hàng, tài khoản chứa PII, tài khoản không chứa PII, hạ tầng và secret dùng một lần rồi phân vùng bằng các công cụ như trình quản lý mật khẩu SaaS, họ KeePass, HashiCorp Vault hay
pass sẽ phù hợp hơn
Vì sao tôi không còn khuyến nghị Bitwarden nữa
- Gần 4 năm trước, bài viết cách tự vận hành như LastPass trên OpenBSD đã được harden đã giới thiệu cách triển khai Vaultwarden trên một instance OpenBSD hoặc Raspberry Pi bare metal và dùng nó làm backend cho ứng dụng client của Bitwarden
- Sau nhiều năm trực tiếp sử dụng một cách tiếp cận tương tự, tác giả nay đi đến kết luận rằng không còn khuyến nghị sử dụng Bitwarden
- Các vấn đề cốt lõi được tóm gọn thành: máy chủ chính thức quá nặng, định hướng mã nguồn mở thiếu minh bạch, chất lượng và UX của ứng dụng client kém, các sự cố bảo mật lặp lại và rủi ro của mô hình giao toàn bộ thông tin xác thực cho một trình quản lý mật khẩu duy nhất
Trình quản lý mật khẩu premium theo mô hình cấp phép kép
- Wikipedia mô tả Bitwarden là một dịch vụ quản lý mật khẩu mã nguồn mở premium để lưu trữ thông tin nhạy cảm, do Bitwarden, Inc. sở hữu và phát triển
- Bitwarden phát triển máy chủ chính thức và ứng dụng client cho hầu hết các nền tảng, đồng thời cũng cung cấp sản phẩm SaaS cho người dùng không muốn tự host
- Giá của sản phẩm được host tương đương với các đối thủ cạnh tranh nhưng có khác biệt về tính năng; dù dùng bản host hay tự host thì ứng dụng client vẫn là như nhau
- Bitwarden đã nhận khoản đầu tư tăng trưởng 100 triệu USD từ PSG vào năm 2022, với sự tham gia của Battery Ventures
- Một trình quản lý mật khẩu cố gắng duy trì mã nguồn mở khác với một trình quản lý mật khẩu có nhà đầu tư trong hội đồng quản trị kỳ vọng lợi nhuận từ khoản đầu tư 100 triệu USD; từ thời điểm này, sản phẩm dễ chuyển sang phục vụ nhà đầu tư hơn là người dùng
Sự tương phản giữa máy chủ chính thức và Vaultwarden
- Có ý kiến cho rằng khi tự host Bitwarden, người dùng sẽ khá nhanh rơi vào địa ngục phần mềm doanh nghiệp
- Triển khai Bitwarden server tiêu chuẩn là một backend C# nặng nề, đi kèm MSSQL Express, và không hoạt động cùng các cơ sở dữ liệu thân thiện với Linux như PostgreSQL hay MariaDB
- Tùy quy mô triển khai và yêu cầu về tính sẵn sàng cao, có thể phải dùng Kubernetes, và khi đó sẽ phát sinh thêm overhead cùng độ phức tạp
- Trong các triển khai quy mô nhỏ và trung bình, nhiều người thường ưu tiên Vaultwarden
- Vaultwarden là một máy chủ tương thích Bitwarden không chính thức được viết bằng Rust
- Nó đơn giản và nhẹ hơn Bitwarden server chính thức, tạo ra khác biệt lớn với quản trị viên
- Việc số sao GitHub của Vaultwarden dường như cao gấp khoảng 3 lần bản triển khai chính thức khiến người ta phải nghĩ về cách người dùng kỹ thuật của Bitwarden hiện nhìn nhận hướng đi của stack chính thức
- Với một công ty đã nhận khoản đầu tư Series B trị giá 100 triệu USD, lẽ ra họ có thể cân nhắc mời những người đã tạo ra một backend thành công hơn nhiều tham gia tối ưu hóa và tăng tốc stack chính thức
Bitwarden lite và định hướng mã nguồn mở
- Thay vì tiếp nhận Vaultwarden thành dự án chính thức, Bitwarden dường như đã tuyển dụng nhà phát triển chính của Vaultwarden rồi công bố Bitwarden lite, một phiên bản nhẹ hơn của backend hiện có
- Bitwarden lite vẫn là dịch vụ dựa trên .NET của Microsoft, và bị đánh giá là vẫn cần lượng RAM nhiều hơn hơn 3 lần so với một instance Vaultwarden thông thường
- Tính chất mã nguồn mở của Bitwarden đã trở nên mờ nhạt hơn trong khoảng hơn 1 năm qua
- Cuối năm 2024, người dùng phát hiện client có thêm dependency
@bitwarden/sdk-internal mới
- Giấy phép của nó có câu chữ cấm dùng SDK này cho phần mềm không phải Bitwarden, cho bản triển khai không tương thích Bitwarden, hoặc để phát triển SDK khác
- Với một sản phẩm tự nhận là mã nguồn mở, kiểu điều khoản giấy phép như vậy được xem là một bước ngoặt rất lớn
- Sau phản ứng dữ dội đáng kể từ cộng đồng, Bitwarden gọi đây là “lỗi đóng gói”, và cuối cùng đã cấp phép lại SDK theo GPLv3
- Về mặt kỹ thuật thì vấn đề đã được giải quyết, nhưng về mặt triết lý, dự án vẫn cho cảm giác phần miễn phí và mã nguồn mở chỉ là mồi nhử, còn sản phẩm thực sự là thuê bao SaaS, trong khi cộng đồng chỉ đóng vai trò cung cấp issue và bản dịch
- Một bài phê bình liên quan là The freeware parts are bait
Ứng dụng client mới là vấn đề cốt lõi
- Ngay cả khi bỏ qua backend, vấn đề lớn nhất của Bitwarden vẫn được cho là ứng dụng client
- Có đánh giá rằng các tính năng được quảng bá không hoạt động như kỳ vọng, những chức năng cơ bản vẫn còn thiếu dù sản phẩm đã ra mắt 10 năm, và giao diện người dùng kém khi so với các lựa chọn thay thế có mức giá tương tự
- Nếu Bitwarden là nỗ lực thuần túy của cộng đồng FOSS thì có thể còn bỏ qua được những thiếu sót này, nhưng vì đây là công ty nhận vốn đầu tư mạo hiểm nên khó áp dụng cùng một tiêu chuẩn như vậy
- Việc cộng đồng bị trói trong các quy trình mang tính quan liêu cũng cho thấy Bitwarden là sản phẩm của công ty hơn là nỗ lực cộng đồng
Vấn đề di chuyển kho dữ liệu
- Khoảng 1 năm trước, tác giả đã hỗ trợ một người dùng muốn chuyển từ sản phẩm cạnh tranh sang Bitwarden với ý định ủng hộ phần mềm mã nguồn mở bằng khoản thuê bao hàng năm thay vì nền tảng độc quyền
- Trong quá trình nhập kho dữ liệu từ trình quản lý mật khẩu cũ sang tài khoản Bitwarden mới đã phát sinh vấn đề, và theo báo cáo lỗi trên GitHub, ít nhất có một kho đã cần đến cách lách kỹ thuật đáng kể mới có thể nhập thành công
- Tính năng di chuyển và nhập dữ liệu đã được quảng bá ở nhiều nơi trong tài liệu và tài liệu marketing của Bitwarden, và đã có nhiều người dùng khác gặp cùng vấn đề này
- Dù vậy, Bitwarden dường như không xử lý issue đó mà lại yêu cầu mở thêm một cuộc thảo luận khác trên diễn đàn cộng đồng
- Kiểu quan liêu mang phong cách doanh nghiệp này không phù hợp với hình ảnh của phần mềm mã nguồn mở, và càng khó biện minh khi một tính năng được quảng bá ở cả phần mềm mã nguồn mở lẫn sản phẩm trả phí lại không thực sự hoạt động
- Khi thử cùng thao tác nhập dữ liệu đó trên các lựa chọn thay thế độc quyền của Bitwarden thì mọi thứ hoạt động không vấn đề gì
Thiếu khả năng di chuyển mục giữa các kho
- Vấn đề di chuyển dữ liệu không chỉ giới hạn ở lần nhập ban đầu
- Ngay cả khi muốn chuyển mục giữa kho organization và kho individual bên trong Bitwarden, cho đến nay vẫn không có chức năng đúng nghĩa để di chuyển các mục đã chọn sang nơi khác
- Nếu chỉ có vài mục đăng nhập thì có thể sao chép rồi chỉnh sửa, nhưng trong các tình huống phải sắp xếp hàng trăm mục, rời khỏi tổ chức hoặc hợp nhất nhiều tổ chức, công việc lặp lại trở nên quá mức
- Cách vòng chính thức mà bộ phận hỗ trợ Bitwarden và chuỗi thảo luận cộng đồng khuyến nghị là xuất kho gốc thành JSON không được mã hóa, chỉnh sửa tệp rồi nhập lại vào kho đích
- Quy trình này tạo ra rủi ro bảo mật khi hơn 500 thông tin xác thực có thể nằm ở dạng văn bản thuần trong
~/Downloads hoặc các thư mục đồng bộ đám mây như Dropbox, OneDrive, iCloud
- Khi xuất dữ liệu, tệp đính kèm sẽ bị bỏ sót, các mục trong thùng rác, lịch sử mật khẩu và dấu thời gian cũng vậy
- Đây là cách khó có thể chấp nhận với các tổ chức phụ thuộc vào tệp đính kèm như tệp khóa SSH, khóa giấy phép, mã khôi phục dạng hình ảnh, hoặc vào lịch sử mật khẩu vì mục đích tuân thủ và kiểm toán
- Việc một sản phẩm lẽ ra phải là nguồn sự thật duy nhất của thông tin xác thực mà đến năm thứ 10 vẫn không cung cấp nút chuyển nguyên vẹn 500 mục sang kho khác cho thấy rõ các ưu tiên kỹ thuật của họ
Cập nhật client làm hỏng tính năng
- Bitwarden phát hành các bản cập nhật client cho người dùng mà không báo trước, và các bản cập nhật này đôi khi có thể khiến việc truy cập kho bị vô hiệu ở phía client
- Trong lúc đi xa, khi điện thoại được cắm qua đêm, F-Droid đã cập nhật Bitwarden, và sáng hôm sau không thể truy cập kho trong ứng dụng Bitwarden cần dùng để đăng nhập ngân hàng
- Phải mất thời gian mới xác định được nguyên nhân, rồi xác nhận tình hình qua issue của bitwarden/android và thảo luận của Vaultwarden
- Có thể tránh được tình huống tệ hơn nhờ đang có UPDC dùng để host backend Bitwarden
- Việc đẩy một bản cập nhật có vẻ chứa thay đổi giao thức gây đổ vỡ giữa client và backend tạo cảm giác thiếu trách nhiệm, và dẫn đến kết luận rằng không thể tin tưởng Bitwarden đối với người dùng phải tin cậy trình quản lý mật khẩu ở chế độ ngoại tuyến
- Sau đó đã tắt cập nhật tự động của client Bitwarden và xuất ảnh chụp mới nhất của toàn bộ mật khẩu sang bản sao lưu cục bộ dựa trên KeePassChi, KeePassXC, KeePassDX
- Vấn đề này, trái với khẳng định của nhân viên Bitwarden, được cho là không chỉ riêng Vaultwarden
- Ứng dụng Android đã được viết lại hoàn toàn từ .NET MAUI sang Kotlin native trong năm 2024, và sau khi v2024.10.1 phát hành, bị đánh giá là các bản phát hành hàng quý đều tiếp tục xuất hiện hồi quy
Trải nghiệm người dùng và chất lượng ứng dụng desktop·mobile
- Bitwarden bị đánh giá là một trong những ứng dụng tệ nhất xét về UI trên điện thoại và desktop theo cảm nhận chủ quan
- Dù đã dùng trong nhiều năm, vẫn ngại mở extension ungoogled-chromium hay ứng dụng desktop·mobile của nó
- Việc build ứng dụng desktop dựa trên Electron từ mã nguồn là cực kỳ phiền phức, còn Flatpak dựng sẵn thì không hoạt động đúng trên Wayland
- Client và extension có hỗ trợ dùng ngoại tuyến, nhưng không có vẻ được thiết kế xoay quanh việc dùng ngoại tuyến
- Khi mở ứng dụng mobile hoặc extension trình duyệt sẽ có độ trễ như thể đang cố kết nối tới backend
- Trong cấu hình không đặt backend trên Internet công cộng, độ trễ này có thể kéo dài từ vài giây đến vài phút
- Dường như không có cách tắt đồng bộ khi mở khóa kho để tránh chờ đợi không cần thiết
- Danh sách đăng nhập Vault của extension trình duyệt cũng bất tiện
- Thông thường các trình quản lý mật khẩu khác sẽ điền vào form đăng nhập khi nhấp vào mục trong danh sách
- Trong Bitwarden, nếu nhấp vào toàn bộ mục trong danh sách thì màn hình chi tiết sẽ mở ra, còn muốn tự động điền phải bấm nút Fill nhỏ ở bên phải
- Khi rê chuột, mục danh sách lớn được tô sáng nhưng thao tác tự động điền thực tế chỉ gắn với nút nhỏ, nên khó thao tác
- Dường như cũng không có thiết lập đổi hành vi để nhấp vào mục danh sách là tự động điền, còn nút nhỏ là mở chi tiết
- Các vấn đề tương tự cũng lặp đi lặp lại trên Hacker News và trong cộng đồng
- Ngay cả các yêu cầu tính năng như lịch sử chỉnh sửa đơn giản theo từng mục còn tồn tại trên diễn đàn cộng đồng từ năm 2021 cũng chưa được xử lý, và các đại lý MSP cũng công khai chỉ trích là “phát triển tính năng chậm như băng trôi”
Giao diện nguy hiểm của Bitwarden CLI
- Bitwarden CLI cũng bị đánh giá là có giao diện người dùng kém
- Lệnh
list của công cụ bw xuất ra chi tiết của mọi mục, bao gồm mật khẩu và mã TOTP, ngay cả khi không có cờ bổ sung như --show-credentials
- Thiết kế này bị chỉ trích là chưa cân nhắc đầy đủ tình huống vô tình pipe
bw list sang nơi khác và làm lộ toàn bộ thông tin xác thực ngoài ý muốn
- Việc Bitwarden CLI là một công cụ terminal được viết bằng TypeScript cũng bị xem là vấn đề
- Có nhiều runtime và dependency
- Stack JavaScript bị đánh giá là không còn là lựa chọn nhẹ nhàng để vô tư chạy trong môi trường CI nữa
Lịch sử bảo mật
- Vai trò cốt lõi của trình quản lý mật khẩu là giữ an toàn cho người dùng và lưu trữ thông tin xác thực một cách an toàn
- Là sản phẩm đã tồn tại từ năm 2016, Bitwarden bị đánh giá là đã trải qua không ít vấn đề bảo mật được triển khai trong môi trường production thực tế
- Điều đó không có nghĩa từng sự cố riêng lẻ đều mang tính chí mạng, nhưng các vấn đề được nêu ra gồm thái độ bảo mật thiên về phản ứng sau sự cố, cách đáp lại kiểu “hành vi được chủ đích” trước những phát hiện gây bối rối, sự phụ thuộc của CLI cốt lõi về bảo mật vào toolchain Node.js, và mô thức xử lý chậm các vấn đề mà các nhà nghiên cứu bên ngoài đã cảnh báo từ trước
-
2023: KDF
- Vào tháng 1/2023, ngay sau vụ xâm phạm LastPass, nhà nghiên cứu bảo mật Wladimir Palant công bố phân tích cho thấy con số 200.001 vòng lặp PBKDF2 mà Bitwarden quảng bá trên thực tế gần với 100.000 hơn
- Lý do là số vòng lặp bổ sung phía máy chủ chỉ được áp dụng cho băm mật khẩu chủ dùng để đăng nhập, chứ không áp dụng cho khóa mã hóa bảo vệ dữ liệu kho
- Đánh giá cho rằng kẻ tấn công truy cập được kho bị rò rỉ có thể bỏ qua máy chủ hoàn toàn, và mức bảo mật thực tế trở nên giống LastPass
- Số vòng lặp mặc định phía client khi đó cũng chỉ là 100.000, thấp hơn khuyến nghị OWASP thời điểm đó, và lo ngại này đã được nêu ra từ năm 2020
- Bitwarden cuối cùng đã nâng mặc định lên 600.000 vòng lặp và thêm hỗ trợ Argon2, nhưng thay đổi ban đầu chỉ áp dụng cho tài khoản mới nên người dùng hiện có phải tự đổi thiết lập KDF
-
2023: Vượt qua Windows Hello
- Năm 2023, RedTeam Pentesting công bố lỗ hổng ứng dụng desktop Windows “Bitwarden Heist”
- Lỗ hổng này là CVE-2023-27706, cho phép kẻ tấn công có quyền quản trị viên miền trích xuất khóa giải mã kho từ kho lưu trữ DPAPI cục bộ mà không cần Windows Hello hay hộp thoại mật khẩu chủ
- Các nhà nghiên cứu mô tả rằng bất kỳ tiến trình nào chạy trong phiên người dùng có đặc quyền thấp đều có thể yêu cầu DPAPI cung cấp thông tin xác thực để mở khóa kho
- Bản sửa lỗi được đưa vào phiên bản 2023.4.0, vài tháng sau lần công bố đầu tiên
-
2023: Tự động điền chéo nguồn gốc
- Cũng trong năm đó, CVE-2023-27974 được công bố
- Extension trình duyệt của Bitwarden cung cấp điền thông tin xác thực cả cho iframe khác miền được nhúng trong trang đáng tin cậy nếu miền gốc khớp
- Ví dụ, nếu
trusted.com nhúng iframe attacker.trusted.com và subdomain đó do bên thứ ba kiểm soát, thông tin xác thực có thể bị đánh cắp
- Bitwarden trả lời rằng iframe cần được xử lý theo cách này vì lý do tương thích, và “Auto-fill on page load” không được bật mặc định
- Với những người dùng đã bật tùy chọn đó, đây chỉ là sự an ủi nhỏ
-
2025: Clickjacking dựa trên DOM
- Tháng 8/2025, nhà nghiên cứu bảo mật Marek Tóth công bố một kiểu tấn công clickjacking dựa trên DOM có thể khiến extension trình duyệt Bitwarden tự động điền thông tin thẻ tín dụng và dữ liệu cá nhân từ một trang độc hại chỉ với một cú nhấp chuột
- Lỗ hổng đã được báo cáo vào tháng 4/2025, tức 4 tháng trước khi công bố, nhưng Bitwarden phân loại nó là “moderate severity”
- Bản vá được đưa vào phiên bản 2025.8.2 phát hành đúng ngày lệnh cấm công bố của nhà nghiên cứu kết thúc
-
2026: Shai-Hulud
- Vài ngày trước khi bài viết này được viết, client CLI chính thức của Bitwarden
2026.4.0 đã bị xâm phạm trong cuộc tấn công chuỗi cung ứng Checkmarx đang diễn ra
- Phiên bản gói bị ảnh hưởng dường như là
@bitwarden/cli2026.4.0, với mã độc được đăng trong bw1.js đi kèm gói
- Cuộc tấn công dường như đã lợi dụng một GitHub Action bị xâm phạm trong pipeline CI/CD của Bitwarden, phù hợp với mô thức nạn nhân ở các kho khác trong cùng chiến dịch
- Các tổ chức đã cài gói npm Bitwarden độc hại nên xem đây là một sự cố lộ thông tin xác thực và xâm phạm CI/CD
- Payload tải runtime Bun, giải mã sâu Shai-Hulud giai đoạn 2, rồi thu thập token GitHub và npm, khóa SSH, lịch sử shell, thông tin xác thực AWS, GCP, Azure, secret của GitHub Actions, và cả các file cấu hình MCP mà công cụ AI sử dụng
- Dữ liệu bị đánh cắp được exfiltrate bằng cách tự động tạo kho công khai trên chính tài khoản GitHub của nạn nhân rồi tải dữ liệu lên đó
- Pipeline phát hành npm của Bitwarden bị xâm phạm trong khoảng 19 giờ, đủ thời gian để 334 nhà phát triển tải xuống gói độc hại
- Lập trường chính thức của Bitwarden nhấn mạnh rằng dữ liệu kho của người dùng cuối không bị truy cập, nhưng những người đã chạy
bw trong pipeline CI đã vô tình giao cho kẻ tấn công các bí mật khác có trên máy đó
- Có đánh giá cho rằng nếu
bw là một binary liên kết tĩnh đơn lẻ như thường thấy trong hệ sinh thái Go hoặc Rust, thì bán kính ảnh hưởng kiểu npm này đã không tồn tại
- Dù các cuộc tấn công chuỗi cung ứng cũng đang gia tăng trong hệ sinh thái Go và Rust, rào cản để thực hiện thành công vẫn được đánh giá là cao hơn
Cách tiếp cận sắp tới: chia nhỏ và cô lập
- Đi đến kết luận rằng không có một trình quản lý mật khẩu duy nhất nào phù hợp hoàn hảo với mọi trường hợp sử dụng và mọi cấu hình
- Trong đời sống cá nhân, không cần chia sẻ kho hay từng mật khẩu riêng lẻ với người khác, nhưng trong công việc thì điều này lại phổ biến
- Đăng nhập tài khoản ngân hàng hay cổng bảo hiểm không cần dùng trong công cụ CLI, nhưng vẫn phải truy cập được từ nhiều thiết bị
- Secret lưu trữ đám mây hay khóa riêng SSH dùng để triển khai không cần đồng bộ lên điện thoại, nhưng phải truy cập được từ công cụ dòng lệnh có thể gọi theo chương trình
- Thay vì cố giải quyết mọi thứ bằng một phần mềm hay một nền tảng duy nhất, hợp lý hơn là phân vùng các nhóm thông tin xác thực tốt hơn
- Xét từ góc độ bảo mật, chia các nhóm mật khẩu sang những phần mềm và dịch vụ khác nhau cũng giúp giảm phạm vi ảnh hưởng khi xảy ra rò rỉ dữ liệu
Phân loại thông tin xác thực và lựa chọn công cụ
-
Nhóm A: dự án chuyên môn·dự án khách hàng
- Nhóm A là thông tin xác thực cho các dự án chuyên môn·khách hàng như đăng nhập nền tảng
- Sử dụng trình quản lý mật khẩu SaaS cung cấp chia sẻ kho phù hợp, tích hợp với công cụ mà khách hàng thực sự dùng, SSO, tiện ích mở rộng trình duyệt trên thiết bị doanh nghiệp và nhật ký kiểm toán, đồng thời loại bỏ gánh nặng tự lưu trữ
- Nền tảng này là sản phẩm độc quyền nên bình thường tôi sẽ không ưu tiên, nhưng vì phạm vi của nhóm này chỉ giới hạn ở công việc cho khách hàng nên chấp nhận sự đánh đổi
-
Nhóm B: tài khoản có chứa PII
- Nhóm B là thông tin xác thực của các tài khoản chứa PII, như tài khoản ngân hàng và trang mua sắm trực tuyến
- Những tài khoản này vốn đã chứa thông tin cá nhân như tên, địa chỉ, ngày sinh và thông tin thanh toán, bản thân các dịch vụ đó cũng thường xuyên bị rò rỉ, và có thể kiểm tra trên Have I Been Pwned
- Tôi cho rằng việc trình quản lý mật khẩu bị xâm phạm sẽ không mở rộng một cách đáng kể lượng thông tin mà kẻ tấn công đã biết
- Trong bối cảnh đã có TOTP và Passkeys, điều quan trọng ở đây là khả năng dùng trên nhiều thiết bị, độ tin cậy và khả năng hoạt động ngoại tuyến
- Để không tự động bị xâm phạm cùng với Nhóm A, tôi dùng một trình quản lý mật khẩu đám mây thứ hai, tách biệt, từ nhà cung cấp khác, với mật khẩu chủ và cơ chế khôi phục khác
- Vì dự định chạy ứng dụng di động trên ít nhất một thiết bị GrapheneOS, tôi ưu tiên giải pháp không phụ thuộc vào Google Play Services và nếu có thể thì cung cấp client mã nguồn mở hoặc công khai mã nguồn
-
Nhóm C: tài khoản không có PII
- Nhóm C bao gồm các diễn đàn Internet, website, dịch vụ tôn trọng quyền riêng tư và các tài khoản không lưu giữ PII
- Nhóm này không cần và cũng không muốn dịch vụ đám mây
- Sử dụng KeePassChi, KeePassXC và KeePassDX, đặt tệp cơ sở dữ liệu trong thư mục được đồng bộ giữa các thiết bị bằng Syncthing
- Cách tiếp cận này cũng đã được đề cập trong bài viết trước đây về tự xây dựng Dropbox phi tập trung bằng Syncthing
- Vì bản thân tệp
.kdbx đã được mã hóa, nên ngay cả khi Syncthing bị xâm phạm và kẻ tấn công lấy được tệp, chúng vẫn phải phá lớp mã hóa của KeePassChi/KeePassXC mới có thể lấy được thông tin hữu ích
- Trên di động, KeePassDX trên Android đọc cùng tệp này mà không gặp vấn đề gì
-
Nhóm D: hạ tầng
- Nhóm D là thông tin xác thực hạ tầng như đăng nhập máy chủ và khóa SSH
- Thông tin xác thực cá nhân được lưu theo cùng cách với Nhóm C
- Với thông tin xác thực mà script, tác vụ CI và máy chủ từ xa thực sự sử dụng, tôi dùng HashiCorp Vault
- HashiCorp Vault là công cụ tôi đã vận hành sẵn cho mục đích PKI trong cấu hình OpenBSD
- Dù có phần quá mức với một người dùng đơn lẻ, nó cung cấp chính sách truy cập, xác thực dựa trên token cho các tác nhân tự động hóa, thông tin xác thực sống ngắn khi được hỗ trợ và nhật ký kiểm toán
- Tôi cũng đang xem xét Infisical
-
Nhóm E: thông tin xác thực dùng một lần
- Nhóm E là API key, personal access token và các secret tùy ý chỉ dùng trên dòng lệnh
- Tôi dùng tiện ích
pass lâu đời
pass lưu mỗi secret dưới dạng một tệp mã hóa GPG riêng lẻ trong kho Git- Cấu trúc này đơn giản, dễ kiểm toán và phù hợp với shell script cũng như dotfiles
- Kho Git nằm trên hạ tầng riêng của tôi chứ không phải GitHub, và chỉ đồng bộ thủ công khi thực sự cần truy cập từ máy khác
Kết luận sau khi chuyển từ một kho duy nhất sang nhiều công cụ
- Với những người đến từ thế giới một kho duy nhất, đây có thể trông như một cấu hình quá mức và có quá nhiều thành phần chuyển động
- Sau nhiều năm dùng Bitwarden như giải pháp vạn năng, tôi đi đến đánh giá rằng one size fits all trên thực tế lại là one size fits poorly
- Việc chia thông tin xác thực sang nhiều công cụ ít đau đớn hơn tôi dự đoán ban đầu rất nhiều, vì mỗi công cụ phù hợp hơn với một loại công việc cụ thể
- Ngay cả khi một công cụ nào đó bị xâm phạm, bán kính ảnh hưởng cũng chỉ giới hạn trong một danh mục secret thay vì toàn bộ thông tin xác thực
Phán quyết cuối cùng
- Sau nhiều năm tự lưu trữ Bitwarden, tôi cho rằng sản phẩm này ngày càng rời xa hướng đi mà ban đầu tôi kỳ vọng
- Kiến trúc ưu tiên doanh nghiệp chỉ vừa khít một cách chật vật trên Raspberry Pi, nỗ lực nửa vời với backend nhẹ hơn, tranh cãi về giấy phép SDK, tốc độ xử lý tính năng chậm, các vấn đề UX nhiều năm không được sửa và những sự cố bảo mật lẽ ra không bao giờ nên được phát hành đã cùng nhau tạo nên một bức tranh không khớp với câu chuyện về “trình quản lý mật khẩu mã nguồn mở cho mọi người”
- Điều đó không có nghĩa các lựa chọn thay thế nhìn chung tốt hơn hoặc không có vấn đề
- Trình quản lý mật khẩu vốn dĩ là một bài toán khó, và mọi bên trong lĩnh vực này đều có vấn đề riêng
- Cần xem xét một cách nghiêm ngặt xem bạn đang đặt bao nhiêu niềm tin vào một phần mềm duy nhất để giữ toàn bộ thông tin xác thực, và liệu canh cược đó còn đúng hay không; trong trường hợp này, tôi kết luận rằng đó không còn là lựa chọn đúng nữa
Thảo luận liên quan
1 bình luận
Ý kiến trên Lobste.rs
Cái thông báo nháy tắt JavaScript hiện lên sau khi đổi tab cũng khó chịu, mà tiêu đề tab thay đổi cũng khó chịu nốt
Tôi sẽ không tắt JavaScript theo mặc định. Quá nhiều trang sẽ bị hỏng vì vậy
Với phần lớn các trang tôi hay vào, trình chặn quảng cáo là đủ, còn NoScript chỉ dùng cho một vài trang tệ hại, và có vẻ trang này cũng vừa được thêm vào danh sách đó
Tôi đồng cảm, nhưng ai đó cũng phải làm gì đó. Như bạn nói, sự tiện lợi của việc bật JavaScript ở mọi nơi lớn hơn chuyện chỉ một trang này, nhưng đến một lúc nào đó sự tiện lợi ấy sẽ vượt quá ngưỡng chịu đựng
<title>“steve ballmer nude pics” như một trò “hài hước” ở văn phòng, tôi cố tình tránh nóChỉ là tôi không cho ngoại lệ với các trang tệ hại như vậy, mà xóa chúng khỏi lịch sử duyệt web rồi không quay lại nữa
Đồng thời tôi cũng hiểu ý đồ của tác giả. Có vẻ họ không chỉ muốn troll, mà muốn nói rằng “Ừ, đây là một trò bẩn. Nhưng việc bất kỳ trang nào trên web mặc định đều có thể làm điều này, hay còn tệ hơn nhiều, có hợp lý không?”
JavaScript đã giúp phần lớn sự nghiệp của tôi trở nên khả thi, nhưng chuyện một trang chỉ toàn văn bản hay hình ảnh lại có thể thực thi mã tùy ý mà không có cảnh báo hay dấu hiệu nào, đồng thời dùng CPU, băng thông và các tài nguyên khác không giới hạn, theo tôi là khá điên rồ
Tôi cũng có vài điểm thấy lấn cấn với KeePassXC
Tôi lo việc dùng công cụ AI sẽ đẩy nhanh tốc độ bổ sung những tính năng không mong muốn và cũng không cần thiết vào trình quản lý mật khẩu. Hiện tại có vẻ chủ yếu dùng để sửa lỗi, nhưng một khi phần lớn lỗi đã được sửa thì bước tiếp theo là gì gần như ai cũng đoán được. Sự cám dỗ quá lớn
Gần đây họ còn thêm “hỗ trợ nhiều định dạng tệp hơn trong trình xem tệp đính kèm nội tuyến (hình ảnh, HTML, Markdown), cùng khả năng chỉnh sửa tệp văn bản đính kèm”, mà tôi không hề muốn có loại mã như vậy bên trong một trình quản lý mật khẩu. Đã có trình soạn thảo văn bản và ứng dụng xem tệp riêng rồi
Họ chỉ cần tập trung vào trải nghiệm người dùng tốt nhất có thể để cạnh tranh quyết liệt với 1Password. Tôi thậm chí còn chưa sẵn sàng tin các nhà phát triển KeePassX? KeePassChi? ChiPass? nữa
Ở gần như mọi lĩnh vực tôi đều ưu tiên phần mềm tự do và mã nguồn mở, nhưng với trình quản lý mật khẩu thì tôi đã dùng 1Password suốt một thời gian dài
Đây là một trong số ít lĩnh vực mà tôi quyết định không tiết kiệm tiền, và nhờ mô hình thuê bao nên tôi cho rằng mô hình kinh doanh của công ty là bán một sản phẩm thực sự hoạt động, chứ không phải upsell từ gói miễn phí
Giá mà nó là mã nguồn mở thì tốt hơn, nhưng ngoài chuyện đó ra thì đồng bộ giữa các thiết bị rất ổn định và tiện ích mở rộng trình duyệt cũng làm đúng phần việc của nó mà không có vấn đề gì
Khi họ gần như chặn hẳn cách tự mang phương thức đồng bộ của riêng mình thay vì lưu dữ liệu trên máy chủ của họ, đó là giới hạn cuối cùng với tôi
Hồi đó các ứng dụng khách không phải của Apple cũng không tốt lắm, và việc tôi ngày càng dùng nhiều nền tảng không phải Apple cũng có ảnh hưởng. Có vẻ mấy năm gần đây họ đã cải thiện điểm đó, nhưng tôi chưa thử lại
Lý do tôi rời đi không phải vì tiền. Hiện giờ tôi tự lưu trữ dữ liệu bằng VaultWarden mà vẫn trả tiền cho Bitwarden
Tôi thích phần mềm tự do và mã nguồn mở, nhưng với các công cụ kiểu này thì khả năng kiểm soát nơi dữ liệu được lưu trữ mới là tiêu chí tuyệt đối
Nếu bạn thay đổi thông tin xác thực ở nơi nào đó khác ngoài thiết bị Android, thì lần đầu dùng 1Password trên Android sau đó nó sẽ tự điền thông tin xác thực cũ trước khi giá trị mới kịp đồng bộ
Lần đăng nhập đầu tiên sẽ thất bại, rồi sau khi bạn nhận ra lý do và thử lần hai thì thường sẽ thành công vì lúc đó đồng bộ đã xong. Cực kỳ khó chịu mỗi lần như vậy
Tôi phần lớn đồng ý với các lập luận phản đối Bitwarden, nhưng khá nhiều vấn đề được nêu ra không nghiêm trọng đến vậy, và một số có vẻ bắt nguồn từ các cấu hình tùy biến như VaultWarden hay GrapheneOS
Tôi đã dùng Bitwarden khoảng 5~6 năm, và vấn đề duy nhất tôi gặp là tiện ích mở rộng trình duyệt từng bị chậm một thời gian sau đợt cải tổ UI. Tôi giải quyết bằng cách hạ về phiên bản tiện ích cũ từ các bản phát hành trên GitHub rồi dùng như vậy vài tháng
Nếu đã viết một bài dài như thế thì giá mà họ cũng thực sự nêu ra các lựa chọn SaaS thay thế để chuyển sang. Có thể nếu độc giả tự tìm hiểu thì sẽ chọn được trình quản lý mật khẩu SaaS phù hợp hơn với mình, nên xét cho cùng còn tốt hơn, nhưng vẫn thấy phiền
Tôi muốn nghe về một trình quản lý mật khẩu khác có cung cấp lưu trữ miễn phí, hỗ trợ ngoại tuyến, tự động đồng bộ qua đám mây, tiện ích mở rộng trình duyệt có phím tắt tự điền, ứng dụng di động, và nếu được thì là một lựa chọn mã nguồn mở
Tìm sơ qua thì có vẻ Proton Pass đáp ứng toàn bộ các điều kiện trên cho những ai đang tìm lựa chọn thay thế. Có lúc nào đó tôi sẽ thử, nhưng hiện giờ Bitwarden vẫn rất hợp với tôi
Việc sắp xếp các mục bên trong Bitwarden gần như phát điên
Chỉ cần có kiểu kéo thả các cột để chuyển mục giữa các tổ chức thôi cũng đã tuyệt vời rồi, nhưng hiện giờ chỉ còn lại một hệ thống đầy hạn chế
Thật buồn cười khi với phần mềm trả phí mà giải pháp thực tế duy nhất lại là tự làm công cụ quản trị riêng
Tôi phát hiện ra nó tương đối gần đây và đã chuyển hẳn sang dùng
pass, “trình quản lý mật khẩu UNIX tiêu chuẩn”, cũng rất tốt. Tôi đã dùng hơn 10 năm rồihttps://www.passwordstore.org/
Có vài fork trông vẫn còn hoạt động, nhưng tôi chưa kiểm tra. Có vẻ không có trên Google Play, nhưng có trên F-Droid
Tôi đang dùng Bitwarden nên đã hy vọng bài này sẽ thuyết phục tôi bỏ nó và đề xuất một hướng tiếp cận tốt hơn
Nhưng nếu đã bỏ thời gian viết dài như vậy mà ngoài vài than phiền rất nhỏ nhặt ra lại không có gì, cũng chẳng có đề xuất nào tốt hơn hẳn, thì ngược lại tôi còn thấy yên tâm hơn về Bitwarden
Bitwarden đã triển khai mở khóa kho bằng passkey. Đó là bí mật cuối cùng tôi còn phải nhớ
Nếu là lựa chọn thay thế thì ít nhất cũng phải làm được đến mức đó
Với tư cách người dùng Bitwarden, tôi khuyên dùng nó
Nó rẻ, có đủ mọi tính năng tôi cần, và là phần mềm tự do, mã nguồn mở
Tôi không có thời gian để dùng 5 giải pháp quản lý mật khẩu, 4 công cụ dòng lệnh và 3 mật khẩu chủ. Bitwarden khá tuyệt vời
1Password cho tôi cảm giác tà ác hoàn toàn nên tôi không muốn dính vào
Đây chắc chắn là thứ dễ chuyển sang nhất và cũng dễ chia sẻ với gia đình nhất. Phí thuê bao cũng rất rẻ
Có giải pháp mã nguồn mở nào khác hỗ trợ chia sẻ thông tin xác thực như Bitwarden không?
Tôi đã dùng KeePass/KeePassXC hơn 15 năm, nhưng khi cần chia sẻ một nhóm thông tin xác thực với đồng đội không phải lập trình viên hay với gia đình thì tôi chưa tìm thấy cách nào tốt hơn Bitwarden
Tôi chưa bao giờ thực sự thích Bitwarden, nhưng xét về kho lưu trữ thông tin xác thực cùng khả năng chia sẻ và đồng bộ, nó luôn là lựa chọn ít tệ nhất
Nó có cảm giác doanh nghiệp giống Bitwarden, nhưng trông khá thú vị. Tôi không biết thực tế có tốt không, nhưng có vẻ nó có thể là một lựa chọn thay thế Bitwarden
[0]: https://www.passbolt.com/
Tôi đã dùng keepassXC và keepassDX được một thời gian. Tên gọi của chúng thật sự rất ngớ ngẩn
Tôi đang mong một ngày nào đó sẽ chuyển sang ChiPass
Nếu là GPG thì… chắc là kiểu tự mã hóa cho chính mình bằng RSA chăng?
Nên dùng
age