好吧,我只有两个例子,但它似乎是一个缓慢增长的东西。
首先,我注意到 hotmail.com/live.com 开始这样做 - 在第一个屏幕上询问电子邮件地址,然后您必须单击“下一步”,然后输入您的密码。
... 伙计,这很烦人吗!至少值得信赖的 gmail 知道良好的用户体验。几个月后,gmail 也在做同样的事情。
所以,我认为这个工作流程有一个安全原因,因为它不能用于 UX(?)
但原因是什么?是否与欺骗机器人/使他们的生活更加困难有关?
好吧,我只有两个例子,但它似乎是一个缓慢增长的东西。
首先,我注意到 hotmail.com/live.com 开始这样做 - 在第一个屏幕上询问电子邮件地址,然后您必须单击“下一步”,然后输入您的密码。
... 伙计,这很烦人吗!至少值得信赖的 gmail 知道良好的用户体验。几个月后,gmail 也在做同样的事情。
所以,我认为这个工作流程有一个安全原因,因为它不能用于 UX(?)
但原因是什么?是否与欺骗机器人/使他们的生活更加困难有关?
安全/隐私劣势
如果实施不当,这种方法会带来安全和隐私风险。当没有默认流时,攻击者可以确定电子邮件或登录是否已经存在。正如@Mario Trucco 提到的,这也可以通过注册过程来完成。
实施的原因
我在Google 文档中找到了这个:
这种新的 Google 帐户登录流程将提供以下优势:
- 为补充密码的未来身份验证解决方案做准备
- 为 SAML SSO 用户(例如使用与 Google 不同的身份提供者登录的大学生或企业用户)提供更好的体验
安全优势
在某些情况下,密码不是身份验证的要求。
用户名通常决定如何以及什么对用户进行身份验证;在联合登录中,用户名将标识对用户进行身份验证的身份提供者。该 ID 提供者可能会使用密码,但不是必须的;许多替代登录流程可以被动发生或使用其他信息(例如智能卡或其他硬件令牌、生物识别等)
在这些情况下捕获密码会导致用户输入(敏感)数据两次(因为 Hotmail/Google 不需要该信息,ID 提供者必须第二次请求)或输入不需要的数据全部。
其他答案已经暗示了这一点,但我认为并没有真正阐明像这样的两步登录的潜在安全优势。
这样做可以让您将登录过程的识别和身份验证阶段分开。例如,假设您有一个应用程序,它具有多个级别的用户帐户,具有不同的身份验证要求(例如,有些用户有 2FA,有些用户只有密码身份验证。)或者可能类似于具有不同后端用户数据库的门户系统。
通过获取屏幕一上的用户名,您可以在屏幕二上显示该用户的正确身份验证类型。正如@ludisposed 所提到的,需要为不存在的用户提供“默认”流程,以避免向试图猜测系统上有效帐户的人透露有效/无效的用户名。
将用户名/电子邮件条目与密码分开的主要原因是联合身份验证。在许多现代 Web 应用程序中,用户登录由用户自己的组织(例如您的公司或学校)处理。您正在访问的网站(称为服务提供商)将保留一份与他们建立联合身份验证的组织的列表,以及这些组织使用的域。一旦您提供了您的电子邮件地址,服务提供商将使用域名来确定组织,并将您发送到该组织的登录系统(称为身份提供者)。您在您的组织完成登录,然后您的组织将您发送回原始网站,您的身份信息最常见的是网络 cookie 的形式。想要查询更多的信息,