You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// This is an all-or-nothing check. The server cannot pretend a signing key or security state to be missing, because they are *always* present when the
68
-
// user key is an XChaCha20Poly1305Key. Thus, the server or network cannot lie about the presence of these, because otherwise the entire user account will
69
-
// fail to decrypt.
65
+
// This is an all-or-nothing check. The server cannot pretend a signing key or security
66
+
// state to be missing, because they are *always* present when the user key is an
67
+
// XChaCha20Poly1305Key. Thus, the server or network cannot lie about the presence of these,
68
+
// because otherwise the entire user account will fail to decrypt.
70
69
let is_v2_user = ifletSymmetricCryptoKey::XChaCha20Poly1305Key(_) = user_key {
71
70
true
72
71
}else{
@@ -113,8 +112,8 @@ impl EncryptionSettings {
113
112
let private_key = {
114
113
let dec:Vec<u8> = private_key.decrypt_with_key(&user_key)?;
115
114
116
-
// FIXME: [PM-11690] - Temporarily ignore invalid private keys until we have a recovery
117
-
// process in place.
115
+
// FIXME: [PM-11690] - Temporarily ignore invalid private keys until we have a
Copy file name to clipboardExpand all lines: crates/bitwarden-crypto/src/security_state.rs
+16-11Lines changed: 16 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,24 @@
1
-
//! Security state is a signed object that attests to a user's (or later an organization's) security state.
2
-
//! The security goal is to prevent downgrades of specific features within the user's account by the server / a
3
-
//! networked attacker with TLS introspection access.
1
+
//! Security state is a signed object that attests to a user's (or later an organization's) security
2
+
//! state. The security goal is to prevent downgrades of specific features within the user's account
3
+
//! by the server / a networked attacker with TLS introspection access.
4
4
//!
5
-
//! A security state contains a security version. Based on this version, features can be disabled. Since the server cannot
6
-
//! sign a security state, it can no longer downgrade the feature, because it cannot produce an arbitrary valid signed security state.
5
+
//! A security state contains a security version. Based on this version, features can be disabled.
6
+
//! Since the server cannot sign a security state, it can no longer downgrade the feature, because
7
+
//! it cannot produce an arbitrary valid signed security state.
7
8
//!
8
-
//! Note: A long-term compromised server can record the security state of a user, and then replay this specific state, or the entire account
9
-
//! to downgrade users to previous states. This can be prevented per logged in session by the client, and for bootstrapping a client by
9
+
//! Note: A long-term compromised server can record the security state of a user, and then replay
10
+
//! this specific state, or the entire account to downgrade users to previous states. This can be
11
+
//! prevented per logged in session by the client, and for bootstrapping a client by
10
12
//! using an extended login-with-device protocol.
11
13
//!
12
14
//! To utilize the security state to disable a feature the following steps are taken:
13
15
//! 1. Assume: Feature with format version A is insecure, and cannot be changed by simple mutation
14
16
//! 2. A new, safe format version B is introduced, and an upgrade path created
15
17
//! 3. The upgrade path is made mandatory
16
-
//! 4. After upgrades are run, the sdk validates that all items are in format version B, and the security state can be updated to contain the security version N+1
17
-
//! 5. The client, given a security state with security version N+1 will reject all items that are in format version A.
18
+
//! 4. After upgrades are run, the sdk validates that all items are in format version B, and the
19
+
//! security state can be updated to contain the security version N+1
20
+
//! 5. The client, given a security state with security version N+1 will reject all items that are
21
+
//! in format version A.
18
22
19
23
use std::str::FromStr;
20
24
@@ -34,8 +38,9 @@ export type SignedSecurityState = string;
34
38
35
39
/// The security state is a signed object attesting to the security state of a user.
36
40
///
37
-
/// It contains a version, which can only ever increment. Based on the version, old formats and features are blocked. This prevents a server from downgrading
38
-
/// a user's account features, because only the user can create this signed object.
41
+
/// It contains a version, which can only ever increment. Based on the version, old formats and
42
+
/// features are blocked. This prevents a server from downgrading a user's account features, because
0 commit comments