Tại sao tôi không còn khuyên dùng Bitwarden nữa: Một lời cảnh báo từ người dùng lâu năm
Bài viết chia sẻ trải nghiệm thực tế sau nhiều năm tự-host Bitwarden và lý do tác giả quyết định chuyển đổi sang các giải pháp khác. Từ kiến trúc cồng kềnh, trải nghiệm người dùng kém cho đến chuỗi các sự cố bảo mật nghiêm trọng gần đây, Bitwarden dường như đang dần xa rời khỏi định nghĩa ban đầu về một trình quản lý mật khẩu mã nguồn mở đáng tin cậy.

Tại sao tôi không còn khuyên dùng Bitwarden nữa: Một lời cảnh báo từ người dùng lâu năm
Ảnh bìa minh họa cho bài viết về Bitwarden
Gần bốn năm trước, tôi đã từng hướng dẫn mọi người cách tự chạy một phiên bản LastPass riêng trên nền tảng OpenBSD được gia cố bảo mật. Trong hướng dẫn đó, tôi giải thích cách thiết lập một phiên bản máy chủ — dù là trên đám mây hay cài đặt trực tiếp trên Raspberry Pi — để lưu trữ Vaultwarden làm backend cho các ứng dụng khách Bitwarden. Tuy nhiên, sau khi sử dụng phương pháp này cho chính mình trong nhiều năm, tôi đã đi đến kết luận rằng tôi không còn khuyên dùng Bitwarden nữa. Hãy để tôi giải thích lý do.
Vấn đề của một con quái vật phần mềm
Bitwarden được mô tả là dịch vụ quản lý mật khẩu mã nguồn mở với mô hình freemium, thuộc sở hữu và phát triển bởi Bitwarden, Inc. — một công ty hiện đã gần 10 tuổi. Công ty này không chỉ phát triển máy chủ Bitwarden và các ứng dụng khách cho hầu hết các nền tảng, mà còn cung cấp sản phẩm SaaS cho những người không muốn tự vất vả lưu trữ "con quái vật" cồng kềnh này.
Nếu bạn quyết định tự lưu trữ Bitwarden, bạn sẽ nhanh chóng rơi vào cái mà tôi gọi là "địa ngục phần mềm doanh nghiệp". Triển khai máy chủ chuẩn của Bitwarden là một backend ngôn ngữ C# nặng nề, đi kèm với MSSQL Express và không hoạt động với các cơ sở dữ liệu Linux gốc như PostgreSQL hay MariaDB. Tùy thuộc vào quy mô triển khai, bạn thậm chí có thể cần sử dụng Kubernetes, gây thêm nhiều phức tạp.
Chính vì vậy, nhiều người chuyển sang Vaultwarden — một máy chủ tương thích Bitwarden không chính thức được viết bằng Rust. Bản chất nhẹ nhàng và đơn giản của Vaultwarden tạo ra sự khác biệt lớn đến mức dự án máy chủ không chính thức này có số lượng người quan tâm trên GitHub gấp ba lần so với triển khai chính thức của Bitwarden.
Thay vì tiếp nhận Vaultwarden, Bitwarden dường như mắc phải hội chứng "Không được phát minh ở đây" (NIH). Họ thuê nhà phát triển chính của Vaultwarden nhưng lại tung ra một phiên bản backend "nhẹ hơn" gọi là Bitwarden unified lite, vẫn chạy trên nền tảng Microsoft .NET và tiêu tốn gấp ba lần RAM so với Vaultwarden.
Bước lùi của mã nguồn mở
Về khía cạnh mã nguồn mở, tình hình của Bitwarden đã trở nên mờ ám hơn trong năm qua. Vào cuối năm 2024, người dùng phát hiện ra một phụ thuộc mới được kéo vào các ứng dụng khách có bản quyền cấm sử dụng SDK này để phát triển ứng dụng cho các phần mềm không phải Bitwarden. Sau sự phản đối kịch liệt của cộng đồng, Bitwarden đã gọi đây là "lỗi đóng gói" và cấp phép lại SDK dưới GPLv3. Về mặt kỹ thuật, vấn đề đã được giải quyết, nhưng về mặt triết lý, sự việc này cho thấy Bitwarden đang hướng đi đâu: các phần mềm miễn phí chỉ là mồi câu, sản phẩm thực tế là thuê bao SaaS, và cộng đồng chỉ có để đóng góp lỗi và bản dịch.
Giao diện và trải nghiệm người dùng của Bitwarden còn nhiều hạn chế
Trải nghiệm người dùng và hỗ trợ tồi tệ
Bỏ qua backend, thủ phạm thực sự khiến tôi thất vọng là các ứng dụng khách. Các tính năng được quảng cáo không hoạt động như预期, các tính năng cơ bản bị thiếu vắng sau 10 năm và giao diện người dùng rất kém.
Một ví dụ điển hình là tính năng di chuyển mục giữa các két. Không có tính năng "di chuyển các mục đã chọn" nào tồn tại. Biện pháp chính thức mà hỗ trợ Bitwarden đề xuất là xuất két nguồn thành JSON không được mã hóa, chỉnh sửa thủ công và then nhập lại. Điều này tạo ra một rủi ro bảo mật khổng lồ khi hàng trăm mật khẩu nằm dưới dạng văn bản thuần trên đĩa cứng của bạn. Hơn nữa, quá trình này sẽ làm mất các tệp đính kèm, lịch sử mật khẩu và dấu thời gian.
Các bản cập nhật ứng dụng thậm chí còn đáng sợ hơn. Bitwarden thường xuyên đẩy các bản cập nhật gây ra lỗi khiến két không thể truy cập được. Tôi từng gặp tình huống này khi đi du lịch: ứng dụng trên điện thoại tự cập nhật qua đêm và sáng hôm sau tôi không thể truy cập mật khẩu ngân hàng. Điều này cho thấy Bitwarden hoàn toàn không thể tin tưởng được trong chế độ ngoại tuyến.
Lịch sử bảo mật đáng lo ngại
Một trình quản lý mật khẩu có một nhiệm vụ duy nhất: giữ mật khẩu an toàn. Bitwarden có lịch sử các sự cố đáng báo động:
- 2023 (Lỗi KDF): Số lần lặp PBKDF2 thực tế thấp hơn quảng cáo, khiến bảo mật yếu đi rất nhiều so với LastPass.
- 2023 (Windows Hello bypass): Kẻ tấn công có quyền quản trị miền có thể trích xuất khóa giải mã két từ bộ nhớ DPAPI mà không cần mật khẩu.
- 2023 (Cross-origin autofill): Tiện ích mở rộng tự động điền thông tin vào các iframe cross-domain, dẫn đến rò rỉ thông tin.
- 2025 (Clickjacking): Tiện ích mở rộng bị lừa tự động điền thông tin thẻ tín dụng qua một cú nhấp chuột.
- 2026 (Tấn công chuỗi cung ứng): Đây là giọt nước tràn ly. Gói Bitwarden CLI chính thức (@bitwarden/cli v2026.4.0) đã bị compromise trong cuộc tấn công chuỗi cung ứng Checkmarx. Mã độc đã tải xuống runtime Bun, giải mã một sâu Shai-Hulud và đánh cắp các token GitHub, SSH keys, AWS/GCP credentials.
Việc phân phối một CLI độc hại thông qua kênh chính thức là một thất bại lớn đối với một công ty whose job là giữ bí mật an toàn. Việc sử dụng chuỗi công cụ Node.js cho một công cụ bảo mật quan trọng đã làm gia tăng nguy cơ này.
Chiến lược "Chia để trị"
Thay vì tìm một giải pháp "tất cả trong một", tôi chuyển sang chiến lược phân loại mật khẩu để giảm thiểu rủi ro:
- Nhóm A (Dự án chuyên nghiệp): Sử dụng trình quản lý mật khẩu SaaS độc quyền để chia sẻ két và tích hợp SSO. Tôi chấp nhận sự đánh đổi vì tiện lợi cho khách hàng.
- Nhóm B (Tài khoản có thông tin cá nhân - PII): Sử dụng trình quản lý đám mây riêng biệt từ nhà cung cấp khác với mật khẩu chính khác. Vì các dịch vụ này thường xuyên rò rỉ dữ liệu PII anyway, việc bảo mật tuyệt đối ở đây ít quan trọng hơn khả năng đồng bộ và ngoại tuyến.
- Nhóm C (Tài khoản không PII): Sử dụng KeePassXC/KeePassDX với tệp cơ sở dữ liệu được đồng bộ qua Syncthing. Không cần đám mây, mã hóa đầu cuối.
- Nhóm D (Cơ sở hạ tầng): Sử dụng HashiCorp Vault cho các thông tin đăng nhập máy chủ và khóa SSH, cung cấp chính sách truy cập chi tiết.
- Nhóm E (Thông tin một lần): Sử dụng công cụ
passtiêu chuẩn, lưu từng bí mật dưới dạng tệp GPG được mã hóa trong một kho Git riêng.
Kết luận
Sau nhiều năm tự lưu trữ, tôi thấy Bitwarden đã drift xa khỏi những gì tôi từng tin dùng. Kiến trúc ưu tiên doanh nghiệp, nỗ lực nửa vời cho backend nhẹ, các vấn đề cấp phép, tốc độ phát triển tính năng chậm chạp, trải nghiệm người dùng tồi tệ và chuỗi sự cố bảo mật liên tiếp đều cho thấy bức tranh không giống với "trình quản lý mật khẩu mã nguồn mở cho mọi người" nữa. Tôi khuyên bạn nên xem lại mức độ tin tưởng mà bạn đặt vào một phần mềm duy nhất cho tất cả thông tin nhạy cảm của mình.
Bài viết liên quan

Phần mềm
Ableton Live MCP: Biến AI thành trợ lý sản xuất âm nhạc chuyên nghiệp
03 tháng 5, 2026

Công nghệ
Sự trở lại của TUI: Khi giao diện dòng lệnh lại lên ngôi
03 tháng 5, 2026
Công nghệ
Cái chết của Scrum: Được xây dựng cho một thế giới chậm hơn, được thực hiện bởi những người đã rời đi
03 tháng 5, 2026
