关于受信任设备
受信任设备 SSO 可为企业终端用户提供零知识和端到端加密的无密码体验。这可以防止用户因忘记主密码而被锁定,让他们享受简化的登录体验。
受信任设备 SSO 适用于云组织,未来版本将支持自托管组织。
要开始使用受信任设备 SSO:
- 1.
- 2.
- 3.
入职
登录
批准
密钥轮换
然后询问用户是否想要记住或信任此设备。当他们选择这样做时:
- 1.客户端生成新的设备密钥。该密钥永远不会离开客户端。
- 2.客户端生成新的 RSA 密钥对:设备私钥和设备公钥。
- 3.用户的账户加密密钥使用未加密的设备公钥进行加密,然后将结果值作为公钥-已加密的用户密钥发送到服务器。
- 4.设备公钥使用用户的账户加密密钥进行加密,然后将结果值作为用户密钥-已加密的公钥发送到服务器。
- 5.设备私钥使用第一个设备密钥进行加密,然后将结果值作为设备密钥-已加密的私钥发送到服务器。
最重要的是,当用户开始登录时,公钥-已加密的用户密钥和设备密钥-已加密的私钥将从服务器发送到客户端。
如果用户需要轮换其账户加密密钥,将使用用户密钥-已加密的公钥。
当某个用户在已受信任的设备上使用 SSO 进行身份验证时:
- 1.用户的公钥-已加密的用户密钥(用于解密密码库数据的账户加密密钥的加密版本)从服务器发送到客户端。
- 2.用户的设备密钥-已加密的私钥(解密公钥-已加密的用户密钥所需的未加密版本)从服务器发送到客户端。
- 3.客户端使用设备密钥对设备密钥-已加密的私钥进行解密,设备密钥从未离开过客户端。
- 4.现在未加密的设备私钥用于解密公钥-已加密的用户密钥,从而产生用户的账户加密密钥。
- 5.用户的账户加密密钥解密密码库数据。
当某个用户使用 SSO 进行身份验证,并选择使用未 受信任的设备(即设备对称密钥不存在于该设备上)解密其密码库时,他们需要选择一种方法来批准该设备,并选择信任该设备,以便将来无需进一步批准即可使用。接下来会发生什么取决于所选的选项:
- 从其他设备批准:
- 1.
- 2.用户现在可 以使用解密后的账户加密密钥解密其密码库数据。如果用户选择信任该设备,则会按照入职选项卡中的说明与客户端建立信任。
- 请求管理员批准:
- 1.发起请求的客户端向 Bitwarden 数据库中的验证请求表 POST 一个请求,其中包括账户电子邮件地址、唯一的身份验证请求公钥ª 和访问代码。
- 2.
- 3.请求获得管理员批准后,被批准客户端会使用请求中包含的身份验证请求公钥对用户的账户加密密钥进行加密。
- 4.然后,被批准客户端将加密后的账户加密密钥 PUT 到验证请求记录,并标记为请求已完成。
- 5.发起请求的客户端 GET 到加密后的账户加密密钥,然后使用身份验证请求私钥ª 对它进行本地解密。
- 6.使用解密后的账户加密密钥,与客户端建立信任关系,详见入职选项卡。
ª - 身份验证请求公钥和私钥是为每一个无密码登录请求生成的唯一密钥,其存在时间与请求的存在时间相同。如果请求未被批准或被拒绝,请求将在 15 分钟后过期并从数据库中清除。
- 使用主密码批准:
- 1.
- 2.使用解密后的账户加密密钥,按照入职选项卡中的说明与客户建立信任。
当某个用户轮换其账户加密密钥时,正常轮换过程如下:
- 1.用户密钥-已加密的公钥从服务器发送到客户端,然后使用旧的账户加密密钥(又称用户密钥)对其解密,得到设备公钥。
- 2.使用未加密的设备公钥对用户的新的账户加密密钥进行加密,然后将结果值作为新的公钥-已加密的用户密钥发送到服务器。
- 3.使用用户的新的账户加密密钥对设备公钥进行加密,然后将结果值作为新的用户密钥-已加密的公钥发送到服务器。
- 4.为此用户持久保存在服务器上的所有其他设备的受信任设备加密密钥都会被清除。这样,服务器上就只保留该单个设备所需的三个密钥(公钥-已加密的用户密钥、用户密钥-已加密的公钥和在此过程中未被更改的设备密钥-已加密的私钥)。
任何现在未受信任的客户端都必须通过批准选项卡中说明的方法之一重新建立信任。
虽然使用受信任设备 SSO 可以消除对主密码的需求,但并非在所有情况下都能消除主密码本身:
- 如果用户是在受信任设备 SSO 激活之前入职的,或者如果他们从组织邀请中选择了创建账户,则他们的账户将保留其主密码。
根据您的客户端内存中是否有主密码哈希(由客户端应用程序最初被访问的方式决定),它可能会表现出以下行为变化:
功能 | 影响 |
---|---|
验证 |