验证身份的密码是什么
In December 2014, I published Would You Implement Passwordless Login? It expanded on articles such as Justin Balthrop’s Passwords are Obsolete and Ben Brown’s Is it time for passwordless login? The Passwordless project for Node.js has inspired others, including options for PHP and Ruby.
2014年12月，我发表了《您会实施无密码登录吗？ 它扩展了诸如贾斯汀·巴尔索普 ( Justin Balthrop)的“ 密码已过时”和本·布朗(Ben Brown)的文章的时间。 Node.js的无密码项目激发了其他人的灵感，其中包括PHP和Ruby的选项。
I mentioned considering passwordless authentication for a client project. I’m pleased to say it’s been operating for several months and has been a revelation. More about that shortly — but first, let’s recap …
我提到过考虑为客户端项目进行无密码身份验证。 我很高兴地说它已经运行了几个月，这是一个启示。 不久之后将有更多信息-但首先，让我们回顾一下...
We’re using the same authentication methods devised at the dawn of the web. Unfortunately, passwords are increasingly broken:
我们使用的是网络黎明时设计的相同身份验证方法。 不幸的是，密码越来越多地被破坏：
People rarely create strong passwords. Surveys report one in ten accounts use something from the top twenty most popular passwords. “123456” is used by more than 4% accounts; “password” remains the second most-used.
人们很少创建强密码。 调查显示 ，十分之一的帐户使用了前20个最流行的密码中的某些。 超过4％的帐户使用“ 123456”； “密码”仍然是第二常用的密码。
People use the same terrible password on multiple sites. If you happen to crack someone’s Facebook login, you can probably access their PayPal account. Your single password is only as good as the security of the weakest system you use. 人们在多个站点上使用相同的可怕密码。 如果您碰巧破解了某人的Facebook登录名，则可以访问其PayPal帐户。 您的单个密码仅与所使用的最弱系统的安全性一样好。Corporation hacks are increasingly common and attract mainstream media interest. It’s an easy route to make a name for yourself, extract revenge or indulge in blackmail. Few companies are prepared for acts of cyber-terrorism and, despite the usual claims of “sustained sophisticated attacks”, many breaches are simple SQL injections caused by poor development techniques.
公司黑客攻击越来越普遍，并引起了主流媒体的关注。 这是一条为自己起名，报仇或沉迷勒索的简单方法。 很少有公司为网络恐怖主义行为做好准备，尽管通常声称“持续的复杂攻击” ，但许多漏洞都是由于不良的开发技术导致的简单SQL注入。
From a coding perspective, authentication is tedious and mistakes are made. Checking credentials is the start of your problems: you need to ensure there are no cracks in security, hash strings using strong (and slow) algorithms, allow users to reset forgotten passwords and answer support calls from confused users who are seemingly unable to remember or type a short string correctly. 从编码的角度来看，身份验证很繁琐，而且会出错。 检查凭据是您问题的开始：您需要确保安全性，使用强(慢速)算法的哈希字符串没有裂痕，允许用户重置忘记的密码并回答看似无法记住或困惑的困惑用户的支持电话正确输入短字符串。 Alternative solutions such as biometrics or OAuth depend on hardware or suitable social media accounts. Few sites implement it well, and still need to revert back to email/password methods for some users. 诸如生物识别或OAuth之类的替代解决方案取决于硬件或适当的社交媒体帐户。 很少有网站能很好地实现它，但对于某些用户，仍需要还原为电子邮件/密码方法。The premise of passwordless authentication is that passwords are unnecessary when the majority of users have secure personal messaging accounts such as email and SMS. Applications can leverage these systems:
无密码身份验证的前提是，当大多数用户具有安全的个人邮件帐户(例如电子邮件和SMS)时，不需要密码。 应用程序可以利用以下系统：
To log in, the user visits a site and enters an ID such as an email address. 要登录，用户访问站点并输入ID，例如电子邮件地址。 They are sent a message with a link; they click it and are logged in. 向他们发送带有链接的消息； 他们单击它并登录。In other words, the application creates a random, one-time password, and whispers it to the user whenever they need to access. It’s a similar process to resetting your password — which many users do every login anyway! Email is an obvious choice, but any other messaging service can be used — such as SMS, Slack, Skype, instant messaging or even Twitter direct messages. Multiple options could be offered if you don’t want to rely on a single system.
换句话说，该应用程序会创建一个随机的一次性密码，并在用户需要访问时将其私语给用户。 重置密码的过程与之相似，很多用户无论如何都要进行每次登录！ 电子邮件是显而易见的选择，但可以使用任何其他消息传递服务-例如SMS，Slack，Skype，即时消息传递，甚至Twitter直接消息。 如果您不想依赖单个系统，则可以提供多个选项。
It’s a little more complex behind the scenes to ensure only one person can use the login link. The general process is as follows:
要确保只有一个人可以使用登录链接，幕后操作要复杂一些。 大致过程如下：
When entered, the server verifies an account exists for the email address. 输入后，服务器将验证该电子邮件地址的帐户存在。 The server creates two tokens, such as 24-character hex GUIDs, and associates both with this login attempt. The first token is sent back to the login device — typically as a browser cookie. The second token is encoded in a link sent to the user by email. 服务器创建两个令牌，例如24个字符的十六进制GUID，并将这两个令牌与此登录尝试相关联。 第一个令牌通常作为浏览器cookie发送回登录设备。 第二令牌被编码在通过电子邮件发送给用户的链接中。 When the link is clicked, the server will receive both tokens and verify them against a single login attempt. Optionally, it can make further checks to ensure the link has been clicked within a few minutes and the IP address and browser user-agent string have not changed. 单击链接后，服务器将接收两个令牌并针对一次登录尝试对其进行验证。 (可选)它可以进行进一步检查，以确保在几分钟之内单击了链接，并且IP地址和浏览器用户代理字符串未更改。 If everything verifies, a real session is started and the user is logged in. If anything fails, all associated tokens can be invalidated; it’s impossible to use them again. 如果一切都经过验证，则将启动真实会话，并且用户已登录。如果发生任何故障，则所有关联的令牌都可以失效；否则，所有令牌都将失效。 无法再次使用它们。The benefits of passwordless authentication:
无密码身份验证的好处：
It’s considerably simpler for users. There are no passwords to create or store. You don’t need a social media account or third-party software other than access to your messaging system. It’s impossible to register without valid credentials. 对于用户而言，这要简单得多。 没有要创建或存储的密码。 除了访问您的邮件系统之外，您不需要社交媒体帐户或第三方软件。 没有有效的凭证就无法注册。 It’s more secure. No passwords are stored and there’s nothing to hack or guess. Even if someone intercepts a message, they’d only have one of the two tokens and couldn’t log in. 更安全。 没有存储密码，没有任何东西可以破解或猜测。 即使有人拦截了一条消息，他们也只有两个令牌之一，无法登录。 It’s cost-effective. There’s less code to develop and deploy. Login code is mostly handled by another service with robust security. Your support team is freed from endless password problems. 具有成本效益。 开发和部署的代码更少。 登录代码主要由具有强大安全性的其他服务处理。 您的支持团队将摆脱无尽的密码问题。Logging in takes a little longer — but so does using a password manager! Passwordless authentication can be offered on applications which have reasonably long session timeout periods, or where users only need infrequent access. Shopping sites, social networks, forums, ticketing and content management systems are good use cases.
登录需要花费更长的时间- 但是使用密码管理器也是如此！ 可以在会话超时时间较长或用户只需要很少访问的应用程序上提供无密码身份验证。 购物站点，社交网络，论坛，票务和内容管理系统都是很好的用例。
It would be strange to use passwordless authentication on a messaging system, since you’d require another to log in! Nor would you want your bank depending solely on AOL for their security, although secondary identification processes could supplement it.
在消息传递系统上使用无密码身份验证会很奇怪，因为您需要其他人才能登录！ 您也不想让银行完全依靠AOL来保证其安全性，尽管辅助识别过程可以对其进行补充。
Passwordless can be considered if you’re creating a new application. However, updating an existing application with many users who currently have passwords is more problematic. I suggest running passwordless authentication in parallel rather than switching to a new login process overnight. Offer it as a choice — especially to users who reset their password — and assess uptake after a few months to determine whether it’s viable.
如果要创建新的应用程序，可以考虑使用无密码。 但是，使用许多当前具有密码的用户更新现有应用程序会遇到更多问题。 我建议并行运行无密码身份验证，而不是在一夜之间切换到新的登录过程。 作为一种选择(特别是给重置密码的用户)，可以选择它，并在几个月后评估使用率，以确定它是否可行。
I implemented passwordless authentication on a new application used by a client for several hundred internal personnel and external customers. Around half the userbase have good IT skills and access daily, so their sessions rarely expire. The other half are mostly managers who log in once or twice per month — many forgetting or mistyping passwords.
我在一个新的应用程序上实施了无密码身份验证，该应用程序由客户使用，用于数百名内部人员和外部客户。 大约一半的用户群拥有良好的IT技能，并且每天都有访问权限，因此他们的会话很少过期。 另一半主要是经理，他们每月登录一次或两次，其中许多忘记或错误地输入了密码。
The biggest issue: clients must be convinced.
最大的问题： 必须说服客户 。
“Passwordless” sounds insecure, and few people will have seen it used elsewhere. I was lucky: the client had a single technically-savvy project manager who understood the concept. Even then, I agreed to add passwords if anything failed.
“无密码”听起来不安全，很少有人会看到它在其他地方使用过。 我很幸运：客户只有一个精通技术的项目经理，他了解这个概念。 即使这样，如果发生任何故障，我也同意添加密码。
It was plain sailing from that point onward. For technical reasons, I had to integrate my own implementation rather than rely on a third-party library. It took less than one day, and there was no need for the usual password management, hashing and resetting nonsense which we normally develop and test.
从那时起，一切都很顺利。 由于技术原因，我不得不集成自己的实现，而不是依赖第三方库。 它花费了不到一天的时间，并且不需要通常我们开发和测试的常规密码管理，哈希和重置废话。
The biggest bonus: users understand passwordless authentication. The process is simple, but it’s best to provide simple instructions at all stages. For example:
最大的好处是： 用户了解无密码身份验证 。 该过程很简单，但是最好在所有阶段都提供简单的说明。 例如：
A login link has been emailed to you. Please check your spam folder if it does not arrive.
登录链接已通过电子邮件发送给您。 如果没有，请检查您的垃圾邮件文件夹。
Please click this link to log in … You have 10 minutes to open this link in the same browser.
请单击此链接登录。。。您有10分钟的时间在同一浏览器中打开此链接。
No one was confused. No one struggled. No one praised the system but no one complained either; people accepted the process and it didn’t get in their way. The number of password-related login issues reduced from three or four per week to zero.
没有人感到困惑。 没有人挣扎。 没有人称赞该系统，但也没有人抱怨。 人们接受了这一过程，但并没有妨碍他们。 与密码相关的登录问题的数量从每周三或四个减少到零。
I couldn’t claim passwordless authentication works everywhere, but the experience has been overwhelmingly positive. I’m a convert. All my applications will be passwordless from now on. Some clients may not be happy — but I’ll just pop a dummy password box on their login form and ignore it!
我不能断言无密码身份验证在任何地方都可以使用，但是这种体验是非常积极的。 我是个convert依者。 从现在开始，我所有的应用程序都将不再使用密码。 有些客户可能不满意-但我只是在他们的登录表单上弹出一个虚拟密码框，然后忽略它！
Have you implemented passwordless authentication? Was it a good or bad experience?
您是否实施了无密码身份验证？ 这是好还是坏的经历？
翻译自: https://www.sitepoint.com/passwordless-authentication-works/
验证身份的密码是什么
