We also need to validate the note sizes on key-rotation.
If we do not validate them before we store them, that could lead to a
partial or total loss of the password vault. Validating these
restrictions before actually processing them to store/replace the
existing ciphers should prevent this.
There was also a small bug when using web-sockets. The client which is
triggering the password/key-rotation change should not be forced to
logout via a web-socket request. That is something the client will
handle it self. Refactored the logout notification to either send the
device uuid or not on specific actions.
Fixes#3152
- Change default Password Hash KDF Storage from 100_000 to 600_000 iterations
- Update Password Hash when the default iteration value is different
- Validate password_iterations
- Validate client-side KDF to prevent it from being set lower than 100_000
We also need to validate the note sizes on key-rotation.
If we do not validate them before we store them, that could lead to a
partial or total loss of the password vault. Validating these
restrictions before actually processing them to store/replace the
existing ciphers should prevent this.
There was also a small bug when using web-sockets. The client which is
triggering the password/key-rotation change should not be forced to
logout via a web-socket request. That is something the client will
handle it self. Refactored the logout notification to either send the
device uuid or not on specific actions.
Fixes#3152
As mentioned in #3111, using a very very large vault causes some issues.
Mainly because of a SQLite limit, but, it could also cause issue on
MariaDB/MySQL or PostgreSQL. It also uses a lot of memory, and memory
allocations.
This PR solves this by removing the need of all the cipher_uuid's just
to gather the correct attachments.
It will use the user_uuid and org_uuid's to get all attachments linked
to both, weither the user has access to them or not. This isn't an
issue, since the matching is done per cipher and the attachment data is
only returned if there is a matching cipher to where the user has access to.
I also modified some code to be able to use `::with_capacity(n)` where
possible. This prevents re-allocations if the `Vec` increases size,
which will happen a lot if there are a lot of ciphers.
According to my tests measuring the time it takes to sync, it seems to
have lowered the duration a bit more.
Fixes#3111
When importing to Vaultwarden (or Bitwarden) notes larger then 10_000
encrypted characters are invalid. This because it for one isn't
compatible with Bitwarden. And some clients tend to break on very large
notes.
We already added a check for this limit when adding a single cipher, but
this caused issues during import, and could cause a partial imported
vault. Bitwarden does some validations before actually running it
through the import process and generates a special error message which
helps the user indicate which items are invalid during the import.
This PR adds that validation check and returns the same kind of error.
Fixes#3048
Recent versions of the Bitwarden clients (see bitwarden/clients#3574)
won't parse non-JSON responses. The most noticeable consequence is that
`/api/accounts/revision-date` responses won't be parsed, leading to
`/api/sync` always being called, even when it's not necessary.
Recent versions of the Bitwarden clients (see bitwarden/clients#3574)
won't parse non-JSON responses. The most noticeable consequence is that
`/api/accounts/revision-date` responses won't be parsed, leading to
`/api/sync` always being called, even when it's not necessary.
Recent versions of the Bitwarden clients (see bitwarden/clients#3574)
won't parse non-JSON responses. The most noticeable consequence is that
`/api/accounts/revision-date` responses won't be parsed, leading to
`/api/sync` always being called, even when it's not necessary.
When importing to Vaultwarden (or Bitwarden) notes larger then 10_000
encrypted characters are invalid. This because it for one isn't
compatible with Bitwarden. And some clients tend to break on very large
notes.
We already added a check for this limit when adding a single cipher, but
this caused issues during import, and could cause a partial imported
vault. Bitwarden does some validations before actually running it
through the import process and generates a special error message which
helps the user indicate which items are invalid during the import.
This PR adds that validation check and returns the same kind of error.
Fixes#3048
Recent versions of the Bitwarden clients (see bitwarden/clients#3574)
won't parse non-JSON responses. The most noticeable consequence is that
`/api/accounts/revision-date` responses won't be parsed, leading to
`/api/sync` always being called, even when it's not necessary.
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
Recent versions of the Bitwarden clients (see bitwarden/clients#3574)
won't parse non-JSON responses. The most noticeable consequence is that
`/api/accounts/revision-date` responses won't be parsed, leading to
`/api/sync` always being called, even when it's not necessary.
Previously the websocket notifications were using `app_id` as the
`ContextId`. This was incorrect and should have been the device_uuid
from the client device executing the request. The clients will ignore
the websocket request if the uuid matches. This also fixes some issues
with the Desktop client which is able to modify attachments within the
same screen and causes an issue when saving the attachment afterwards.
Also changed the way to handle removed attachments, since that causes an
error saving the vault cipher afterwards, complaining about a missing
attachment. Bitwarden ignores this, and continues with the remaining
attachments (if any). This also fixes#2591 .
Further some more websocket notifications have been added to some other
functions which enhance the user experience.
- Logout users when deauthed, changed password, rotated keys
- Trigger OrgSyncKeys on user confirm and removal
- Added some extra to the send feature
Also renamed UpdateTypes to match Bitwarden naming.
- Put groups support behind a feature flag, and disabled by default.
The reason is that it has some known issues, but we want to keep
optimizing this feature. Putting it behind a feature flag could help
some users, and the developers into optimizing this feature without to
much trouble.
Further:
- Updates Rust to v1.66.0
- Updated GHA workflows
- Updated Alpine to 3.17
- Updated jquery to v3.6.2
- Moved jdenticon.js to load at the bottom, fixes an issue on chromium
- Added autocomplete attribute to admin login password field
- Added some extra CSP options (Tested this on Safari, Firefox, Chrome, Bitwarden Desktop)
- Moved uppercase convertion from runtime to compile-time using `paste`
for building the environment variables, lowers heap allocations.
When audit logging was introduced there entered a small bug preventing
the recover-2fa from working.
This PR fixes that by add a new headers check to extract the device-type
when possible and use that for the logging.
Fixes#2985
When audit logging was introduced there entered a small bug preventing
the recover-2fa from working.
This PR fixes that by add a new headers check to extract the device-type
when possible and use that for the logging.
Fixes#2985
The yubico crate uses blocking reqwest, and we called the `verify` from
a async thread. To prevent issues we need to wrap it within a
`spawn_blocking`.
- Put groups support behind a feature flag, and disabled by default.
The reason is that it has some known issues, but we want to keep
optimizing this feature. Putting it behind a feature flag could help
some users, and the developers into optimizing this feature without to
much trouble.
Further:
- Updates Rust to v1.66.0
- Updated GHA workflows
- Updated Alpine to 3.17
- Updated jquery to v3.6.2
- Moved jdenticon.js to load at the bottom, fixes an issue on chromium
- Added autocomplete attribute to admin login password field
- Added some extra CSP options (Tested this on Safari, Firefox, Chrome, Bitwarden Desktop)
- Moved uppercase convertion from runtime to compile-time using `paste`
for building the environment variables, lowers heap allocations.
When audit logging was introduced there entered a small bug preventing
the recover-2fa from working.
This PR fixes that by add a new headers check to extract the device-type
when possible and use that for the logging.
Fixes#2985
It looks like Bitwarden, in-the-end, didn't changed the export feature
on v2022.11.0, and now have put in on v2023.1.0.
This patch now changes that to the same version.
Before those new clients are being released, we should see if they
changed that again, and adjust where needed.
It looks like Bitwarden, in-the-end, didn't changed the export feature
on v2022.11.0, and now have put in on v2023.1.0.
This patch now changes that to the same version.
Before those new clients are being released, we should see if they
changed that again, and adjust where needed.
As discussed in #2937, this will limit the amount of encrypted
characters to 10.000 characters, same as Bitwarden.
This will not break current ciphers which exceed this limit, but it will prevent those
ciphers from being updated.
Fixes#2937
- Several cleanups and code optimizations for Emergency Access
- Fixed a race-condition regarding jobs for Emergency Access
- Some other small changes like `allow(clippy::)` removals
Fixes#2925
As discussed in #2937, this will limit the amount of encrypted
characters to 10.000 characters, same as Bitwarden.
This will not break current ciphers which exceed this limit, but it will prevent those
ciphers from being updated.
Fixes#2937
- Several cleanups and code optimizations for Emergency Access
- Fixed a race-condition regarding jobs for Emergency Access
- Some other small changes like `allow(clippy::)` removals
Fixes#2925
- Several cleanups and code optimizations for Emergency Access
- Fixed a race-condition regarding jobs for Emergency Access
- Some other small changes like `allow(clippy::)` removals
Fixes#2925
- Several cleanups and code optimizations for Emergency Access
- Fixed a race-condition regarding jobs for Emergency Access
- Some other small changes like `allow(clippy::)` removals
Fixes#2925
As discussed in #2937, this will limit the amount of encrypted
characters to 10.000 characters, same as Bitwarden.
This will not break current ciphers which exceed this limit, but it will prevent those
ciphers from being updated.
Fixes#2937
sirux88
BlackDex
Jeremy Lin
Alex Martel