Vaultwarden có an toàn không? Checklist hardening

Vaultwarden có an toàn không? Câu trả lời ngắn gọn

Vaultwarden an toàn ở nơi quan trọng nhất: mọi mục trong vault được mã hóa trên thiết bị của bạn trước khi đến server. Server chỉ lưu các blob mà nó không thể đọc. Ngay cả khi ai đó sao chép toàn bộ database, họ vẫn cần master password để lấy được dữ liệu hữu ích.

Câu trả lời này phụ thuộc nhiều vào cách bạn cấu hình. Admin panel sử dụng token dễ đoán. Một cổng của container được publish ra toàn bộ Internet. Một config.json dạng plaintext. Một file tar backup nằm trong home directory trên chính máy đó. Không vấn đề nào trong số này liên quan đến cryptography. Tất cả đều là lý do khiến vault tự host bị lấy sạch dữ liệu.

Phần dưới đây giả định rằng bạn đã có một bản cài đặt đang hoạt động. Nếu chưa có, trước tiên hãy thiết lập theo hướng dẫn cài đặt Vaultwarden trên VPS, sau đó quay lại và thực hiện lần lượt danh sách này.

Dữ liệu thực tế server lưu trữ

Vaultwarden triển khai data model của Bitwarden. Tên, username, password, ghi chú và URI của một mục trong vault được mã hóa bằng key dẫn xuất từ master password trên client, trước khi gửi bất kỳ request nào. Nội dung file đính kèm cũng được mã hóa theo cách tương tự. Server nhận dữ liệu không thể đọc, kèm theo một UUID (universally unique identifier).

Một số dữ liệu không phải ciphertext. Bạn cần biết chính xác đó là những gì:

• Địa chỉ email của account, ở dạng plaintext.
• Các thiết lập KDF (key derivation function) và salt, vì client cần chúng để tạo lại key trong lần đăng nhập tiếp theo.
• Hash phía server của hash master password mà client gửi, được dùng để xác thực chính lần đăng nhập đó.
• Metadata: membership trong organisation, tên thiết bị và thời điểm đăng nhập gần nhất.
• Secret của phương thức two-factor bảo vệ lần đăng nhập Vaultwarden. Secret này nằm không mã hóa trong bảng twofactor, vì server phải tính code dự kiến để so sánh với code của bạn. Đây không phải secret TOTP (time-based one-time password) mà bạn lưu bên trong một mục trong vault; secret đó được mã hóa như mọi field khác.

Thư mục dữ liệu có kích thước nhỏ. Với bản cài Docker, đó là thư mục bạn mount tại /data.

sudo ls -l /vw-data/

db.sqlite3 chứa gần như toàn bộ state. attachments/ chứa các file đã upload, mỗi file tương ứng với một UUID, và đây là loại dữ liệu quan trọng duy nhất không nằm trong các table của database. sends/ chứa attachment của Send và được thiết kế để dùng tạm thời. icon_cache/ có thể xóa và tạo lại. rsa_key.pem cùng các file liên quan dùng để ký JWT (JSON web tokens) của người dùng đã đăng nhập. Vì vậy, bản sao của private key này có thể được dùng để giả mạo session đăng nhập vào vault. config.json chỉ xuất hiện sau khi bạn bật trang admin. Project nói rõ: file này chứa admin token và thông tin xác thực SMTP ở dạng plaintext.

Vì vậy, threat model thực tế là quyền truy cập filesystem, không phải cryptography trên network. Quyền đọc thư mục đó cho phép lấy toàn bộ địa chỉ email của người dùng, secret 2FA đăng nhập, key dùng để giả mạo session và bản sao offline của mọi vault để tấn công tùy ý. Mọi bước bên dưới đều nhằm ngăn người khác truy cập thư mục đó.

Khắc phục admin token trước

/admin là một control panel có toàn quyền: danh sách user, lời mời, xóa user và mọi runtime setting. Nó chỉ được bảo vệ bằng một shared secret duy nhất. Không có username. Không có two-factor riêng cho từng user.

Các hướng dẫn cũ yêu cầu bạn tạo ADMIN_TOKEN bằng openssl rand -base64 48. Cách này vẫn hoạt động, nhưng ghi secret dưới dạng plaintext vào config.json và file compose. Vaultwarden cũng chấp nhận chuỗi Argon2 PHC (password hashing competition), nên giá trị được lưu sẽ là hash. Tạo một chuỗi trên container đang chạy:

docker exec -it vaultwarden /vaultwarden hash

Hoặc không cần tác động đến container đang chạy:

docker run --rm -it vaultwarden/server /vaultwarden hash

Lệnh yêu cầu nhập password 2 lần, sau đó in ra một dòng bắt đầu bằng $argon2id$. Với cài đặt bare metal, chạy ./vaultwarden hash. Nếu muốn dùng trực tiếp argon2 CLI, project công bố các tham số tối thiểu theo OWASP:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Đây là lỗi dễ khiến bạn mất cả giờ. Chuỗi PHC chứa rất nhiều ký tự $, còn Docker Compose dùng $ để nội suy biến. Nếu dán chuỗi chưa escape vào block environment:, giá trị truyền đến container sẽ bị biến đổi, khiến /admin từ chối token dù token đó chính xác. Có 2 cách an toàn. Trong docker-compose.yml, nhân đôi mọi ký tự $:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

Trong file .env, không cần escape, nhưng phải dùng dấu nháy đơn:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Sau đó giới hạn rate của panel và rút ngắn session:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Nếu có 3 lần thử sai trong 5 phút, panel sẽ ngừng trả lời client đó. Admin session hết hạn sau 20 phút kể từ khi đăng nhập, dù bạn vẫn đang sử dụng panel, vì hoạt động không gia hạn session.

Tốt hơn hết là tắt hẳn trang này. Hầu hết instance chỉ cần dùng trang này một lần để cấu hình SMTP và mời những user đầu tiên, sau đó không cần nữa. Để tắt, không đặt ADMIN_TOKEN hoặc DISABLE_ADMIN_TOKEN, xóa mọi key "admin_token" khỏi config.json, rồi tạo lại container. Xóa key khỏi file rất quan trọng vì trang admin ghi setting vào đó, và giá trị trong config.json sẽ được ưu tiên hơn environment. Chỉ xóa variable là chưa đủ để đóng trang.

Đóng đăng ký trước khi có người phát hiện domain

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED mặc định là true. Hãy giữ nguyên thiết lập này thì bất kỳ ai truy cập được domain của bạn đều có thể tạo account, và dữ liệu của họ nằm trong cùng db.sqlite3 với dữ liệu của bạn. Đặt thành false rồi thêm người dùng bằng lời mời từ trang admin; cách này yêu cầu SMTP hoạt động. INVITATIONS_ALLOWED cũng mặc định là true và cho phép admin của organization mời người khác. Điều này phù hợp khi bạn tin tưởng người dùng, và nên đặt thành false trên instance chỉ có một người dùng. Nếu chỉ một số domain nhất định được phép đăng ký, SIGNUPS_DOMAINS_WHITELIST=example.com hẹp hơn đăng ký mở nhưng kém an toàn hơn nhiều so với lời mời.

SHOW_PASSWORD_HINT mặc định là false và nên giữ nguyên. Khi bật tùy chọn này nhưng chưa cấu hình SMTP, nhập một địa chỉ email hợp lệ vào form đăng nhập sẽ trả về gợi ý master password của account đó. Điều này vừa làm lộ gợi ý, vừa xác nhận địa chỉ đó tồn tại.

Nếu instance của bạn từng cho phép đăng ký mở trong bất kỳ khoảng thời gian nào, hãy mở trang admin và đọc danh sách user trước khi cho rằng instance chỉ có account của bạn.

Cổng bạn không định public

Docker image lắng nghe trên cổng 80 bên trong container. Bản cài bare-metal mặc định dùng ROCKET_PORT=8000. Lệnh run được tài liệu hướng dẫn sẽ publish cổng như sau:

--publish 127.0.0.1:8000:80

Prefix 127.0.0.1: mới là phần quyết định. Nếu viết -p 8000:80 thay vì vậy, Docker sẽ bind 0.0.0.0 và tạo các rule DNAT (destination network address translation) trong table nat. Các rule này được xử lý trước các chain filter do ufw quản lý. Vì vậy ufw status báo rằng cổng bị deny, trong khi cổng đó vẫn trả lời Internet bình thường. Cơ chế đầy đủ được giải thích trong hướng dẫn về các cổng Docker bypass ufw.

Kiểm tra chính xác tiến trình nào đang lắng nghe:

sudo ss -tlnp | grep 8000

Kết quả đúng là chỉ có một dòng bind vào 127.0.0.1:8000. Dòng bind vào 0.0.0.0:8000 nghĩa là vault đang được expose trực tiếp. Sửa mapping, sau đó tạo lại container, vì port binding được cố định khi container được tạo và docker compose restart sẽ không thay đổi nó:

docker compose up -d --force-recreate

Một cổng khác vẫn xuất hiện trong các guide cũ: 3012, là cổng WebSocket riêng. Vaultwarden đã bỏ hỗ trợ cổng này từ phiên bản 1.31.0 vì traffic notification đã chuyển sang cổng HTTP chính. WEBSOCKET_ENABLED và WEBSOCKET_PORT đã deprecated từ phiên bản 1.29.0 và sẽ bị bỏ qua. Tùy chọn hiện tại là ENABLE_WEBSOCKET, mặc định là true. Nếu firewall hoặc file compose của bạn vẫn mở cổng 3012, hãy đóng cổng đó.

Kết thúc TLS tại reverse proxy, không phải trong Rocket

Vaultwarden có thể tự phục vụ TLS (transport layer security) thông qua Rocket, web framework của nó, nhưng project khuyến cáo không làm vậy trong môi trường production. TLS tích hợp của Rocket không hỗ trợ SNI (server name indication) nghiêm ngặt. Đây cũng là lý do tài liệu hardening khuyên bạn truy cập instance bằng hostname và không bao giờ dùng bare IP address. Các dải public IP luôn bị scan, và vault phản hồi trên một IP address sẽ bị phát hiện.

Các phần quan trọng trong server block của nginx:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx mặc định client_max_body_size là 1 MB. Nếu thiếu dòng đó, việc upload attachment sẽ fail với 413 Request Entity Too Large trong nginx error log, còn Vaultwarden hoàn toàn không ghi log. Các header Upgrade và Connection chuyển WebSocket handshake đến /notifications/hub. Nếu bỏ chúng, vault vẫn hoạt động, nhưng các thay đổi sẽ không xuất hiện trên những thiết bị khác cho đến khi bạn tự reload trang.

Caddy có cấu hình ngắn hơn và tự lấy certificate:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Sau đó khai báo proxy với Vaultwarden:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER mặc định đã là X-Real-IP. Vì vậy, bạn cần bảo đảm proxy thực sự đặt header đó. Vaultwarden cũng chỉ chấp nhận header từ các address được liệt kê trong IP_HEADER_TRUSTED_PROXIES. Giá trị mặc định là local: mọi non-global address, bao gồm proxy trên cùng host hoặc trong cùng container network. Nếu proxy kết nối từ public address, bạn phải thêm address đó vào danh sách. Nếu thiếu header hoặc header đến từ address không được tin cậy, mọi log line và mọi login rate limit sẽ ghi nhận address của proxy, thay vì address của client. Khi đó, các lần đăng nhập fail của một attacker sẽ bị tính cho mọi user trên instance. Nếu dùng IP_HEADER=X-Forwarded-For, phiên bản 1.37.4 sẽ lấy address ngoài cùng bên phải không phải trusted proxy. Vì vậy, hãy liệt kê mọi proxy trong chain, kể cả CDN đứng trước nginx. Đồng thời đặt DOMAIN thành URL https thực tế, vì Vaultwarden dùng giá trị này để tạo link invitation và password reset. Các security key WebAuthn cũng được ràng buộc với origin đó.

Có một chi tiết nhiều người bỏ sót: WebSocket connection truyền session token trong query string, dưới dạng /notifications/hub?access_token=[JWT]. Giá trị này sẽ xuất hiện rõ trong proxy access log. Hãy redact parameter access_token trong log format, hoặc bảo đảm các log đó không được ship đến bất kỳ nơi nào bạn không kiểm soát.

Chặn brute force tại endpoint đăng nhập

Rate limit được bật mặc định (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Chúng làm chậm attacker. Chúng không ngăn được attacker hoàn toàn. fail2ban có thể làm việc đó, nhưng cần đọc được các lần đăng nhập thất bại của Vaultwarden. Với Docker, cách đơn giản là dùng file log, vì Vaultwarden không tự ghi file này:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Mỗi lần đăng nhập thất bại sẽ tạo đúng một dòng. Đây là chuỗi mà filter của bạn phải khớp:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Ghi filter vào /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Và jail vào /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Nếu Vaultwarden chạy dưới dạng systemd service thay vì trong container, bạn có thể bỏ qua LOG_FILE: wiki fail2ban của dự án đọc journal bằng backend = systemd và dùng journalmatch trên unit Vaultwarden thay cho logpath.

Nếu bạn vẫn giữ trang admin, hãy thêm jail thứ hai có failregex là ^.*Invalid admin token\. IP: <ADDR>.*$, vì các lần đăng nhập admin thất bại được ghi bằng thông báo khác và login filter sẽ không bao giờ thấy chúng. Sau đó kiểm tra cấu hình:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Jail hoạt động sẽ liệt kê file log của bạn dưới File list và báo Currently failed: 0. Nhập sai mật khẩu 3 lần từ một network khác. Counter sẽ tăng, sau đó địa chỉ sẽ xuất hiện dưới Banned IP list. Nếu counter không bao giờ tăng, nguyên nhân thường gặp là logpath: đây phải là path của file trên host, không phải path /data/... bên trong container. Nguyên nhân thường gặp thứ hai là X-Real-IP bị thiếu hoặc không đáng tin cậy, khiến mọi lệnh ban đều nhắm vào chính proxy của bạn. Phần còn lại của cấu hình, bao gồm SSH jail mà bạn nên chạy sẵn, có trong hướng dẫn fail2ban cho Ubuntu 24.04.

Mật khẩu master vẫn là toàn bộ hệ thống

Mã hóa phía client có nghĩa là mật khẩu master chính là key. Một mật khẩu master ngắn trên instance mà attacker đã sao chép database không được bảo vệ bởi bất kỳ thiết lập nào trong bài viết này, vì attacker có thể tấn công bản sao đó offline với tốc độ mà phần cứng của họ cho phép. Không có thiết lập nào trên server tác động được đến máy của attacker.

PASSWORD_ITERATIONS=600000 rất dễ bị hiểu sai. Nó đặt số vòng lặp cho hash phía server của login hash mà client gửi lên. Template cấu hình của dự án cho biết giá trị mới sẽ được áp dụng cho các user hiện có vào lần đăng nhập tiếp theo. Thiết lập này không tác động đến KDF phía client. KDF mới là thiết lập quyết định chi phí của cuộc tấn công offline vào vault. Thiết lập đó thuộc về từng account và được thay đổi trong Settings, Security, Keys của web vault; thao tác này sẽ mã hóa lại key. Tài liệu của Bitwarden cho biết các client từ 2026.2.1 sẽ tự động tăng thiết lập PBKDF2 dưới 600,000 vòng lặp khi user đăng nhập hoặc unlock bằng mật khẩu master. Tính đến ngày 10 tháng 10 năm 2026, hành vi này chưa được xác nhận với Vaultwarden server và không bao giờ thay đổi thiết lập Argon2id. Vì vậy, người đã đăng ký từ nhiều năm trước có thể vẫn đang dùng thiết lập KDF cũ và thấp hơn. Hãy kiểm tra và thông báo cho họ, vì server không thể làm việc đó thay họ.

Sau đó, bật xác thực two-factor cho từng account. Tính năng này không bảo vệ ciphertext, vì vault key chỉ được tạo từ mật khẩu master. Tuy nhiên, nó ngăn việc chỉ dùng mật khẩu bị đánh cắp để đăng nhập và sync một bản sao. REQUIRE_DEVICE_EMAIL=true bắt buộc gửi email đăng nhập từ thiết bị mới: nếu Vaultwarden không thể gửi email, đăng nhập sẽ thất bại, nên việc đăng nhập từ thiết bị chưa được nhận diện sẽ không diễn ra mà không có thông báo. Tính năng này cần SMTP hoạt động; nếu không, mọi lần đăng nhập từ thiết bị mới đều sẽ bị từ chối.

Sao lưu là điểm các vault tự host thường gặp lỗi

Một tar czf của thư mục dữ liệu, để trong thư mục home trên cùng VPS, sẽ vô hiệu hóa mọi bước ở trên. Archive đó chứa db.sqlite3 với ciphertext của mọi user, rsa_key.pem có thể giả mạo các phiên đăng nhập, và config.json chứa admin token cùng mật khẩu SMTP ở dạng plaintext. Có quyền đọc file đó đồng nghĩa với có quyền đọc vault.

Hai quy tắc là đủ. Đưa archive ra khỏi máy chủ. Mã hóa archive trước khi truyền đi.

Cũng có một vấn đề về tính toàn vẹn dữ liệu. Sao chép db.sqlite3 bằng cp khi service đang chạy có thể tạo ra file đang được ghi dở và không mở được. Bạn sẽ chỉ phát hiện ra lỗi này khi restore. Hãy dùng snapshot của chính SQLite:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

Phần restore, là phần hầu như không ai kiểm thử, được trình bày trong hướng dẫn backup và restore Vaultwarden.

Bạn phải tự gánh những gì khi không dùng Bitwarden hosted

Đây là đánh giá thực tế. Dịch vụ hosted của Bitwarden do đội ngũ có công việc toàn thời gian là vận hành dịch vụ này quản lý, có các cuộc audit bên thứ ba được công bố và có người trực lúc 3 giờ sáng. Tự host đồng nghĩa với việc bạn phải tự quản lý lịch cập nhật bản vá.

Vaultwarden phát hành bản sửa lỗi bảo mật như các bản release thông thường, và các bản release xuất hiện khá thường xuyên. Kiểm tra vào ngày 10 October 2026 dựa trên release feed của dự án, bản release hiện tại vẫn là 1.37.4, được phát hành ngày 5 October 2026. Release notes đề cập đến 7 security advisory, trong đó advisory nghiêm trọng nhất được xếp hạng High, đồng thời khuyến nghị cập nhật sớm nhất có thể. Đây là bản release thứ 4 kể từ 1.37.0 vào ngày 24 July 2026: 1.37.1 được phát hành ngày 29 July, 1.37.2 ngày 22 August (bắt buộc đối với client phiên bản 2026.8.0 trở lên), và 1.37.3 ngày 13 September. Bản 1.37.3 thu hồi remember token của 2FA khi credential hoặc 2FA thay đổi, đồng thời áp dụng rate limit cho các endpoint prelogin và auth request. Nếu bạn vận hành các organisation có admin mà bạn không hoàn toàn tin cậy, release notes của 1.37.4 cũng đề nghị rotate API key của từng organisation sau khi cập nhật. 1.37.4 cũng thay đổi địa chỉ được đọc từ X-Forwarded-For; nội dung này đã được đề cập trong phần reverse proxy ở trên. Một instance được bạn thiết lập từ 1 năm trước rồi bỏ quên vẫn đang chạy code đã cũ 1 năm. Tag latest không tự giải quyết vấn đề này: một container đang chạy vẫn giữ image mà nó đã khởi động cùng, cho đến khi bạn chạy docker compose pull và recreate container. Hãy thiết lập unattended upgrades trên Ubuntu cho các package của host, đồng thời đặt lịch nhắc cập nhật container vào thời điểm mà bạn thực sự sẽ đọc.

Kết luận mà một người đọc thực tế nên rút ra là: cryptography ở đây dựa trên thiết kế của Bitwarden và vẫn đáp ứng yêu cầu, còn rủi ro vận hành hoàn toàn chuyển sang bạn. Nếu bạn cập nhật bản vá và backup dữ liệu sang một nơi khác, một instance Vaultwarden trên VPS do bạn kiểm soát là nơi hợp lý để lưu password. Nếu bạn sẽ không duy trì được 2 thói quen đó, hãy trả phí cho dịch vụ hosted và dành thời gian cho việc khác. Bản so sánh theo từng feature nằm trong So sánh Vaultwarden với Bitwarden tự host.

Hardening máy chủ bên dưới container

Vaultwarden là một process trên máy Linux. root trên máy đó vẫn có thể đọc /vw-data bất kể ứng dụng được cấu hình thế nào. Chạy container bằng user không có quyền đặc biệt với user: "1000:1000" trong file compose, đồng thời đặt owner của thư mục dữ liệu cho khớp. Gắn mọi thứ mà container không cần ghi ở chế độ chỉ đọc bằng :ro. Sau đó đóng cửa vào: Hardening SSH trên VPS hướng dẫn chỉ cho đăng nhập bằng key và tắt xác thực bằng password. Đây là cách ngăn kiểu tấn công đơn giản vượt qua tất cả các lớp bảo vệ trên.

FAQ

Người khác có thể đọc mật khẩu của tôi nếu họ đánh cắp database Vaultwarden không?

Không trực tiếp. Mỗi mục trong vault được mã hóa trên client bằng key sinh từ master password, vì vậy db.sqlite3 chỉ chứa ciphertext. Ngay lập tức, kẻ tấn công có thể lấy được địa chỉ email của từng account, các thiết lập KDF, metadata đăng nhập và thiết bị, cùng các secret two-factor trong bảng twofactor. Các secret này được lưu không mã hóa vì server phải tính code dự kiến. Kẻ tấn công cũng có thể thử bẻ khóa ciphertext của vault offline trong thời gian tùy ý. Vì vậy, độ dài master password là yếu tố quyết định kết quả.

Tôi nên dùng ADMIN_TOKEN hay vô hiệu hóa hoàn toàn trang admin?

Nếu có thể, hãy vô hiệu hóa trang này. Hầu hết instance chỉ cần dùng nó một lần để cấu hình SMTP và mời user, sau đó không cần nữa. Để vô hiệu hóa, không đặt ADMIN_TOKEN và DISABLE_ADMIN_TOKEN, xóa mọi key "admin_token" khỏi config.json, rồi tạo lại container. Chỉ xóa environment variable là chưa đủ, vì các thiết lập được ghi từ trang admin nằm trong config.json và có độ ưu tiên cao hơn. Nếu vẫn giữ trang này, hãy lưu token dưới dạng Argon2 hash được tạo bằng vaultwarden hash thay vì một chuỗi random plaintext, đồng thời đặt ADMIN_RATELIMIT_MAX_BURST=3.

ADMIN_TOKEN của tôi đúng nhưng /admin từ chối. Lỗi ở đâu?

Gần như luôn là do nội suy $. Chuỗi Argon2 PHC chứa nhiều ký tự $, còn Docker Compose sẽ mở rộng chúng thành variable bên trong block docker-compose.yml environment:. Vì vậy, container nhận một giá trị đã bị biến đổi dù file của bạn trông vẫn đúng. Trong file compose, hãy viết mỗi $ thành hai lần $$, hoặc chuyển giá trị vào một file .env được đặt trong dấu nháy đơn. Cách này không cần escape. Sau đó tạo lại container, vì restart không nạp các thay đổi về environment.

Tôi còn cần mở port 3012 cho notification không?

Không. Hỗ trợ traffic WebSocket trên port 3012 đã bị xóa trong Vaultwarden 1.31.0 vì notification đã được chuyển sang HTTP port chính. WEBSOCKET_ENABLED và WEBSOCKET_PORT đã deprecated từ 1.29.0 và bị bỏ qua. Thiết lập hiện tại là ENABLE_WEBSOCKET, với giá trị mặc định là true. Hãy đóng 3012 trong firewall và xóa port này khỏi file compose. Sau đó, bảo đảm reverse proxy forward các header Upgrade và Connection, vì đồng bộ real-time hiện phụ thuộc vào chúng.