编辑：该方案已被标准化为WebAuthn - 改用它！

我有一个用户群，实际上并不太倾向于为网站创建安全密码。它们也几乎完全在移动设备上，所以我想尝试一些不同的东西，而不是他们输入“password1”然后等待它被猜到。所以，首先，一些假设：

• 无论如何，Web 浏览器几乎总是会记住您的密码。
• 移动设备越来越多地获得更安全地识别特定用户的功能（例如，触摸 ID）。
• 这使用 HTTPS；恶意客户端（拦截）在很大程度上不是问题。

由此产生的影响：

• 网站对设备进行身份验证，而设备对用户进行身份验证。因此，我们不妨为网站 <-> 设备使用比选择不当的密码更好的东西。

鉴于此，目的是使用客户端生成的密钥对。之前问过的最相似的问题是Using RSA for Web Application Authentication，但是这种方法似乎有点不同。

所以，协议本身。一、加盟流程：

• 客户端生成一个 RSA 密钥对。
• 公钥被发送到服务器（通过 HTTPS）。每个设备只会发生一次。
• 服务器将公钥存储为设备。
• 服务器创建一个帐户并将设备与该帐户相关联。[一个]
• 使用公钥对第一个会话令牌和新设备 ID 进行加密，并将结果发送回客户端。设备 ID 既是数字又是随机生成的字符串。
• 客户端对其进行解密，存储设备 ID 和私钥，并将 IP 锁定会话令牌设置为其 cookie。
• 所有进一步的请求都使用会话令牌进行身份验证。

登录（通常是由于更改了 IP）

• 客户端通过发送设备 ID 告诉服务器它是哪个设备。
• 服务器要求客户端通过使用其存储的该设备的公钥加密新会话令牌并发送它来证明它。
• 客户端解密数据并将会话设置为 cookie。
• 如果它确实是它所说的那个人，那么会话现在是有效的。

将设备添加到帐户（例如，用新手机替换刚洗过的手机）：

• 设备通过与上述类似的 join 获取自己的设备 ID，但不创建帐户；[A] 不发生。该设备当前能够进行身份验证，但未与任何帐户关联。（而且这种关联纯粹是在服务器端）。
• 在新设备上输入您的电子邮件地址（或其他一些与帐户相关的信息，例如用户名）。
• 服务器识别请求的帐户并向其发送包含链接的电子邮件或 SMS。
• 用户加载链接（在任何设备上）。这会导致服务器将新设备与原始帐户相关联，前提是它在例如 24 小时内。

已知漏洞：

以下漏洞也都与您的典型密码系统有关。

• 它与电子邮件帐户/短信接收器等一样强大。
• SSLStrip 和 XSS 用于获取存储的私钥，就像它们可以获取 document.cookie 或自动填充的用户/密码字段一样。虽然整个站点只有 HTTPS，但周围的基础设施可能存在一些未知的漏洞。
• 其他人可以抓住物理设备并使用该站点。

密码系统的好处：

• “密码”是私有的，甚至来自服务器，有助于防止数据泄露和 MITM。

• “密码”文本要强得多，因为它基本上相当于一个 300-500 个字符长的区域。

• 服务器只包含一个公钥列表。通过数据泄漏获得此列表的人仍然必须破坏 RSA。

• 这是不可钓鱼的，因为用户从不直接输入密码。

• 如果入侵者破坏了 HTTPS，即使用 SSLStrip 之类的东西绕过它，他们仍然必须破坏密​​码，因为它不是作为明文在线上的。

• 实际上使用起来更简单；用户至少只需输入一个电子邮件地址。

  鉴于此，我的假设是这样的系统可能比密码提供更多的安全性和简单性。但是，为什么不这样做，应该这样做；我错过了什么吗？或者我应该坚持使用主流密码设置并接受它 - 任何回复将不胜感激！

旁注

• 我知道与此类似的客户端证书，但它们似乎使用复杂的术语和用户体验来让用户理解，因此它们并没有被太多使用。在类似的线程上，不使用密码可能会让用户感到奇怪；它可能被认为不太安全。（？）

• 如果该技术是合理的并且“感知问题”不是问题，我打算将已实施的解决方案开源，以在 Web 上实现更高的安全性/简单性，并对实施进行相应的全面审计。