vaultwarden

hacktoberfest docker vaultwarden rust rocket bitwarden-rs bitwarden

tom27052006 83fd293e01 Add trusted device encryption for SSO logins Lets a user unlock their vault after an SSO login with a key stored on a trusted device instead of a master password, what Bitwarden calls trusted device encryption. Off by default, enabled with `SSO_TRUSTED_DEVICE_ENCRYPTION`, which requires `SSO_ENABLED`. The client generates a key pair plus a device key that never leaves the device and stores three blobs on the device row: the user key wrapped for the device public key, that public key wrapped with the user key, and the device private key wrapped with the device key. The server only keeps and returns them, so a stored trust is worthless without the device itself. A device counts as trusted only while all three are present. Endpoints, matching bitwarden/server's DevicesController: PUT\|POST /devices/<identifier>/keys trust a device POST /devices/<identifier>/retrieve-keys the public halves, for rotation POST /devices/update-trust re-wrap after a key rotation POST /devices/untrust drop the trust of some devices POST /devices/lost-trust client reports a drifted trust `GET /devices`, `GET /devices/identifier/<id>` and the login response now report the real trust state instead of a hard-coded `isTrusted: false`. An SSO login response carries `UserDecryptionOptions.TrustedDeviceOption`, which is what makes the clients offer the flow at all. Upstream ties this to the SSO configuration of an organization; SSO is configured for the whole server here, so the setting decides it, and members of no organization can use it too. A password login never gets these options. When the setting is turned off again, devices that are still trusted keep receiving their keys with `IsTdeOffboarding` set, so their owner can still unlock and set a master password instead of being locked out. `HasAdminApproval` and `HasManageResetPasswordPermission` are always false: approval of a new device by an organization admin is not implemented, and announcing it would leave the client waiting for a request nobody can answer. A new device is unlocked by approving it from an already trusted device or with the master password. Two adjacent fixes this depends on: - `POST /accounts/keys` refused to notice that an account already has a key pair and would happily replace it, which makes every existing cipher undecryptable. It now only accepts keys for an account that has none, and tolerates a repeat of the same keys. The trusted device flow is what makes this reachable in practice: a client that misjudges an existing account as new posts a fresh key pair here. - `POST /accounts/set-password` keyed "account already initialized" off the key pair, so an account created without a master password could never gain one. It now keys off the master password itself and refuses to replace an existing key pair, which is what the check was guarding. Rotating the account keys leaves every device holding a wrapped copy of the previous user key. Those are dropped; the rotating device keeps its own private key so its client can re-wrap the new user key right away via `/devices/update-trust`. A client that skips that call ends up with no trusted device rather than a broken unlock. Covers dani-garcia/vaultwarden#7034.	2 weeks ago
..
down.sql	Add trusted device encryption for SSO logins	2 weeks ago
up.sql	Add trusted device encryption for SSO logins	2 weeks ago

tom27052006 83fd293e01 Add trusted device encryption for SSO logins

Lets a user unlock their vault after an SSO login with a key stored on a
trusted device instead of a master password, what Bitwarden calls trusted
device encryption. Off by default, enabled with
`SSO_TRUSTED_DEVICE_ENCRYPTION`, which requires `SSO_ENABLED`.

The client generates a key pair plus a device key that never leaves the
device and stores three blobs on the device row: the user key wrapped for
the device public key, that public key wrapped with the user key, and the
device private key wrapped with the device key. The server only keeps and
returns them, so a stored trust is worthless without the device itself.
A device counts as trusted only while all three are present.

Endpoints, matching bitwarden/server's DevicesController:

  PUT|POST /devices/<identifier>/keys           trust a device
  POST     /devices/<identifier>/retrieve-keys  the public halves, for rotation
  POST     /devices/update-trust                re-wrap after a key rotation
  POST     /devices/untrust                     drop the trust of some devices
  POST     /devices/lost-trust                  client reports a drifted trust

`GET /devices`, `GET /devices/identifier/<id>` and the login response now
report the real trust state instead of a hard-coded `isTrusted: false`.

An SSO login response carries `UserDecryptionOptions.TrustedDeviceOption`,
which is what makes the clients offer the flow at all. Upstream ties this to
the SSO configuration of an organization; SSO is configured for the whole
server here, so the setting decides it, and members of no organization can
use it too. A password login never gets these options. When the setting is
turned off again, devices that are still trusted keep receiving their keys
with `IsTdeOffboarding` set, so their owner can still unlock and set a
master password instead of being locked out.

`HasAdminApproval` and `HasManageResetPasswordPermission` are always false:
approval of a new device by an organization admin is not implemented, and
announcing it would leave the client waiting for a request nobody can
answer. A new device is unlocked by approving it from an already trusted
device or with the master password.

Two adjacent fixes this depends on:

  - `POST /accounts/keys` refused to notice that an account already has a
    key pair and would happily replace it, which makes every existing
    cipher undecryptable. It now only accepts keys for an account that has
    none, and tolerates a repeat of the same keys. The trusted device flow
    is what makes this reachable in practice: a client that misjudges an
    existing account as new posts a fresh key pair here.
  - `POST /accounts/set-password` keyed "account already initialized" off
    the key pair, so an account created without a master password could
    never gain one. It now keys off the master password itself and refuses
    to replace an existing key pair, which is what the check was guarding.

Rotating the account keys leaves every device holding a wrapped copy of the
previous user key. Those are dropped; the rotating device keeps its own
private key so its client can re-wrap the new user key right away via
`/devices/update-trust`. A client that skips that call ends up with no
trusted device rather than a broken unlock.

Covers dani-garcia/vaultwarden#7034.

2 weeks ago

down.sql

Add trusted device encryption for SSO logins

2 weeks ago

up.sql

Add trusted device encryption for SSO logins

2 weeks ago