1团队密码有多安全?

信息安全 加密 密码 密码管理 同步
2021-09-01 04:14:51

我想请教您对 1Passowrd for Teams 的安全性有何看法。

对于不知道 1Password - Personal use - 如何在此处工作的人,总结一下:您创建一个主密码(很难暴力破解)并使用您的主密码加密所有其他凭据。一切都保存在本地,除了您和曾经使用您的 PC 的任何人都可以访问加密密码。确实安全可靠。

但是,对于 Teams 的 1Password,情况完全不同。如果我能理解的话,每个加密密码都存储在网上。

所以这里也总结一下:

首先,您设置了一个所有团队都在此之上的域。1Password 网络服务器自动创建一个帐户密钥。此外,他们说他们不保存此帐户密钥密码。

此外,作为团队管理员的创建者设置他的主密钥。

稍后,管理员使用他的电子邮件向成员发送邀请。新成员,点击邀请链接,1Password 会为他创建一个不同的帐户密钥,然后该成员创建他的主帐户。

实际的问题是,所有这些加密密码都存储在哪里??????

我可以想象所有共享和个人加密密码都存储在 1Password 数据库中。我对么??

即使它是加密的,它的安全性如何?

如果每个加密的密码都在本地,那么everyhting 会更安全,但是即使加密了,也可以在线存储?每个使用 1Password for Team 的人都应该关心像 LastPass 上的黑客攻击这样的黑客事件吗?关联

3个回答

首先,简短的免责声明。我为 1Password 的创建者 AgileBits 的安全团队工作。

1Password for Teams 与大多数密码管理器一样,使用“主密码”(授予对所有其他密码的访问权限的密码)来创建加密密钥。然后使用该加密密钥来加密您存储的所有其他内容。

与其他密码管理器不同,它使用了一个额外的秘密——一个 128+ 位随机生成的“帐户密钥”。主密码帐户的关键用于执行2保密密钥推导,其中“主解锁码”(MUK) -它保护你所有的密码的关键-是基于这两个的熵。因此,如果您的主密码包含 60 位熵 - 这不是特别高,但是是一个很好的示例值 - MUK 至少有 188 位熵。

AgileBits 无法访问这些值——我们没有您的主密码,也没有您的帐户密钥AgileBits 也不会生成任何用作加密密钥的随机数,因此我们无法拥有您的任何加密密钥。

就之前的答案而言,即使您的主密码被泄露,仍然必须获取帐户密钥,并且它提供超过 128 位。这意味着攻击者必须平均进行 2^127 次试验才能猜出您的Account Key简而言之,如果我告诉您我的主密码是“快车很有趣”,那么您将面临无法克服的计算——枚举 2^127 个可能的帐户密钥值——在你面前。仅仅这一步 - 列举 2^127 个可能的值 - 甚至超出了国家行为者(政府)的能力。

安全有其缺点,我们创建了一种机制来保护您免受我们的侵害,以及我们免受攻击者的侵害,并将您丢失所有信息的风险降至最低。由于我们没有访问您的信息所需的任何秘密,因此我们无法“重置”您的密码或在您忘记时允许您创建新的主密码。这可以防止我们滥用“密码重置”机制并获取您的信息,无论是为了我们自己的利益还是应政府实体的要求。如果我们无法获取您的秘密信息来滥用或披露它,那么黑客就会对我们置之不理(理论上如此),因为他们也无法从我们拥有的数据中获取您的秘密。

我们对“密码重置”问题的创新解决方案称为恢复组恢复组是您团队中的一名或多名成员,他们可以加密访问各个团队成员使用的所有加密密钥。我们也无权访问用于加密恢复密钥集的加密密钥,因此我们也不能滥用它。

我们(或攻击者)不仅无法访问您的加密密钥,而且如果用户丢失了他们的主密码和/或帐户密钥,我们也无法访问恢复对这些密钥的访问所需的机制

如需更多信息,请阅读我们的安全页面它还链接到包含更多信息的安全设计白皮书。

[披露:我为 1Password 的制造商 AgileBits 工作]

在你的问题中,你说

密码网络服务器自动创建一个帐户密钥。

尽管看起来确实是这样,但仔细检查客户端(以及我们的一些文档)会让您知道帐户密钥是由您的客户端创建的,而不是在我们的服务器上创建的。我们的服务器不会生成任何密钥。

所以我们不仅不存储这样的密钥,而且我们已经构建了一些东西,所以我们没有机会存储这样的密钥。

两密钥推导

正如我的同事 @julie-in-austin 在她的回答中解释的那样,此帐户密钥是我们的两密密钥推导 (2SKD)的一部分。另一个秘密是您的主密码。需要这两个秘密来派生用于解密数据的密钥。我们从未见过这两个秘密。

2SKD 的主要目的是即使我们的服务器受到威胁也能保护您。显然,我们并没有计划我们的服务器受到损害,但我们必须计划以防我们的服务器受到影响。如果没有 2SKD,攻击者可能会使用您的数据来发起主密码猜测攻击。对于 2SKD,这样的攻击是不可能的。

一点历史

我们长期以来一直采取的态度是,我们不想以任何形式保存您的数据。我们不能丢失、使用或滥用我们没有的数据。没有敏感的客户数据意味着我们真的没有任何值得窃取的东西。因此,当我们想要提供各种安全和灵活的共享时(很抱歉,我们的销售口号,但这些是我们真正想要添加的功能),我们在不保留客户数据的情况下苦苦思索如何做到这一点。(是的,我们可以开发点对点协议,但它会给用户增加相当大的复杂性,并且必须防御另一类攻击。)

因此,我们从一开始就为 Teams 设计了两件事。首先,不要持有任何“可破解”的东西。其次,什么都学不会“破解”。

我们长期以来一直使用 PBKDF2 之类的防御措施来为捕获的数据提供一些实质性的抗破解性(今天仍然如此)。但最终我们会遇到一堵墙,即通过增加这些东西来减少安全的边际收益。我们想要的东西意味着我们坚持的东西对于破解尝试毫无价值。正如朱莉所说,帐户密钥(永远不会靠近我们的服务器)意味着根据我们持有的数据猜测您的主密码的尝试不受您主密码强度的限制,而是面临来自您帐户的 128 位挑战钥匙。

第二部分是我们甚至不想在身份验证过程中获得任何秘密。因此,我们在登录期间使用密码验证密钥交换 (PAKE) 协议。我们(或任何可能已经通过 SSL/TLS 提供的保密的人)都无法在登录期间学习任何可用的信息。

因此,从最早的计划会议到您所看到的,即使我们受到威胁,您也可以确保您受到保护。这超出了 PBKDF2 之类的通常(并且仍然有用)的机制。

1Password 只是一个密码管理器,但有一个在线选项。它还允许将附加信息存储到其中,例如软件许可证和其他类型的授权。您可以仅在本地存储,也可以与在线存储库同步。

加密的密码存储在 1Password 的网站上。如果在线存储的信息被正确加密,那么只要访问密码不被泄露,它就会非常节省。

该系统有单点故障 (SPOF),如果您丢失了这个主密码,所有密码都会被泄露。但是,如果它简化了在每个网站上不使用相同密码的好习惯,它也可以提高您的安全性。

请注意,该服务的可用性和价格是完全不同的问题。如果站点更改了其 API,您将不得不调整登录数据才能再次登录。而且您仍然需要密码的本地副本,以防万一该服务中断。还有其他管理密码的选项(有些是免费的)。

并且此服务无法防止您的密码在使用受感染的计算机时被盗。因此,如果您想安全连接,您仍然需要随身携带一些设备。(我强调最后一段,注意,这里是 SPOF)。