73 lines
4.2 KiB
Markdown
73 lines
4.2 KiB
Markdown
---
|
|
type: reference
|
|
subtype: api-integration
|
|
title: "Vaultwarden vs Bitwarden Cloud — permission and feature parity gotchas"
|
|
summary: Verified differences between self-hosted Vaultwarden and Bitwarden Cloud that break security designs copied from Bitwarden docs — Edit permission includes delete, no deletion-restriction org policy, no Secrets Manager, trash never auto-purges by default — plus org bot-onboarding gotchas (accept ≠ confirm, collection assignment can silently not persist).
|
|
tags:
|
|
- type/reference
|
|
- tool/vaultwarden
|
|
- domain/credential-management
|
|
- domain/security
|
|
scope: global
|
|
date: 2026-07-09
|
|
last_updated: 2026-07-10
|
|
last_reviewed: 2026-07-09
|
|
related:
|
|
- credvault-integration-master-plan
|
|
source: ruby-gems
|
|
---
|
|
|
|
# Vaultwarden Parity Gotchas
|
|
|
|
Bitwarden's official help docs describe Bitwarden Cloud. Vaultwarden reimplements the server
|
|
and does NOT match on these points (verified 2026-07-09, vaultwarden discussions #6131,
|
|
issue #6269):
|
|
|
|
- **Edit collection permission includes deleting items.** There is NO org setting to
|
|
restrict item deletion to Manage-permission members (that toggle is Cloud-only). A "bot
|
|
with Edit but can't delete" design is impossible server-side — enforce in your wrapper/OS layer.
|
|
- **Manage permission is worse for least-privilege** — it grants collection-membership admin.
|
|
- **Secrets Manager does not exist** in Vaultwarden. Don't plan it as a backend.
|
|
- **Trash never auto-purges by default** — permanent deletion only with
|
|
`TRASH_AUTO_DELETE_DAYS` set. (Cloud docs say 30 days.) Safer, but don't cite "30-day window".
|
|
- **Password history ("last 5")** is written client-side into the cipher; compatible clients
|
|
preserve it, raw API writes can clobber it. Likely works — verify per instance.
|
|
- **`bw` CLI API-key login still requires `bw unlock` + master password** for vault data;
|
|
the API key does not replace the master password. Non-interactive automation needs a
|
|
protected `--passwordfile`.
|
|
- **`bw list items --search` doesn't match custom fields** — filter client-side on parsed JSON.
|
|
- Maintainer (BlackDex) states Vaultwarden "does not support the full range of RBAC/GBAC/CBAC".
|
|
|
|
## Org member (bot) onboarding gotchas (verified 2026-07-09, credvault Phase 0)
|
|
|
|
- **Accept ≠ confirm.** A member who accepts an invite still sees NO organization via
|
|
`bw list organizations` until an org admin explicitly clicks **Confirm** on the member
|
|
(Members page → three-dot menu). Confirm is the step that grants the org key; editing the
|
|
member's role/collections is not it.
|
|
- **Collection assignment can silently fail to persist** — after the admin sets a collection
|
|
in Edit member → Collections, `bw list collections` (bot side) can still return `[]` after
|
|
sync. Verify the collection badge shows on the Members list row; re-open the dialog and
|
|
re-save if not.
|
|
- **`bw sync -f` after any server-side membership change** — login/unlock state alone won't
|
|
refresh org/collection visibility on the client.
|
|
- **Password history verified working** on Vaultwarden: `bw edit` with a changed login
|
|
password preserves the old one in `passwordHistory` with `lastUsedDate`. Custom `fields`
|
|
round-trip intact through `bw list items` JSON.
|
|
|
|
## Credential rotation gotchas (verified 2026-07-10, credvault e2e)
|
|
|
|
- **Master password rotation invalidates cached `bw` logins.** After changing an account's
|
|
master password server-side, `bw unlock` fails (exit 1) even with the correct new
|
|
`--passwordfile` — the cached login holds keys derived from the old password. Fix:
|
|
`bw logout`, then re-login with the API key, then unlock works.
|
|
- **`bw` sessions are per `BITWARDENCLI_APPDATA_DIR`.** A plain `bw logout` in a shell only
|
|
clears the *default* appdata dir; tool-specific dirs (e.g. credvault's
|
|
`~/.config/credvault/bitwarden`) keep their stale session until you log out with the
|
|
matching env var set.
|
|
- **API key rotation changes only `client_secret`** — `client_id` is stable across rotations.
|
|
- **`bw unlock --passwordfile` reads only the first line**, so a trailing newline from an
|
|
editor (nvim etc.) is harmless.
|
|
|
|
Rule of thumb: any "Bitwarden supports X" claim from bitwarden.com/help must be re-verified
|
|
against the deployed Vaultwarden version before it becomes a security assumption.
|