为什么无密码认证能够有效

2014年12月，我发布了一篇名为“Would You Implement Passwordless Login”?它对其他文章做了拓展，例如“Justin Balthrop’s Passwords are Obsolete”和“Ben Brown’s is it time for passwordless login?”Node.js的无密码项目激发了其他语言，包括PHP和Ruby。

我提到过我正在构思一个无密码认证的客户端项目，我很高兴，它已经运转了几个月，并且已经成为一个启示，不久将介绍更多内容，但是首先让我们先复述一遍……

什么是无密码认证？

我们还在使用网络初期设计的认证方式，不幸的是，密码越来越容易破解。

调查显示有十分之一的帐号使用的密码包含在前20个使用最多的密码中，超过4%的帐号使用“12345”作为密码，“password”任然是第二个最常使用的密码。

人们在多个网站上使用同一个糟糕的密码。如果你碰巧破解了某人的facebook的帐号，你就很有可能进入他的的PayPal账户，你的唯一密码就跟你使用的安全性最弱的系统一样糟糕。

群体黑客行为越来越常见并且引起了主流媒体的关注，给自己创建一个名称，提取报复或沉溺于勒索是一件很容易的事。很少公司做好应对恐怖主意的行为准备，很多突破口其实就是由很差的开发技术引起的sql注入，尽管通常都声称是由“持续的攻击”引起的。

从编码的角度来看，身份认证是一个冗长乏味的过程并且容易犯错，检查证书时问题的开始，你需要通过强（或若）算法得出的哈希字符串来确保安全性没有被破坏。允许用户重置忘记的密码，并且给那些似乎不能想起或不能打出密码的困惑的人提供客服电话支持。

还有其他可选的解决方案，如基于硬件的生物识别技术和基于合适的社交媒体帐号的第三方认证，很少有网站能够把它们做好，部分人还是得回到邮箱密码的认证方式。

无密码认证方式的前提是：当用户中的大部分人都拥有一个安全的个人通讯帐号如邮箱或短信时密码不再是必须的。应用程序可以使用下面的系统：

1：登录时，用户访问一个网站并输入邮箱之类的Id。

2：它们发送一条带有链接的信息，点击后就能登录。

换句话说，应用创建了一个随机的、一次性的密码，并且在用户需要访问的时候悄悄地告诉他们。这跟重置密码的过程类似，这是许多用户每次登录的时候都会干的事。邮箱是首选，但是其他的通讯服务也可以被利用，如短信、Slack、Skype，及时消息甚至于Twwiter的直达消息。如果你不想依赖一个系统，你可以多个选择。

系统后台确保登录链接只能有一个人使用比看起来要复杂，通常的处理过程如下：

1.    当进入的时候，系统验证确实存在跟邮箱绑定的帐号；

2.    服务器创建两个标识符，如24个字符的16进制全球唯一标识符，然后把这两个标识符都跟登录尝试相关联。第一个标识符被发送到登录设备，通常是作为一个浏览器的cookie，第二个标识符被编码到链接中发送到用户邮箱；

3.    当链接被点击的时候，服务器将收到两个标识符，通过它们来验证登录尝试，另外，还可以做更进一步的检查来确保链接在几分钟内被点击以及ip地址和浏览器的user-agent字符串没有变。

4.    如果每一个都验证通过，一个真的session被创建，用户登录成功；如果有一个验证不通过，所有相关的标识符都要被销毁，不能再被使用。

无密码认证的好处：

对用户来讲相当简单。不需要创建和存储密码，除了你的通讯服务，不再需要其他的社交帐号或者第三方软件，注册必须要有合法的认证；

更加安全。没有存储密码也就没有东西可以被攻击或猜测，及时某人截取了你的信息，他也只有一个标识符，还是不能登录；

经济上更划算。需要编写和发布的代码更少，登录代码大部分被另外一个具有超强安全性的服务所处理，你的支持团队从无穷无尽的密码问题中解放出来。

无密码认证可以被用在哪？

登录时花的时间更长，但是使用密码管理工具同样花时间。无密码认证适用于那些拥有合理的较长session有效期的应用，或者用户不需要经常登录的应用。购物网站、社交网络、论坛、订票系统和内容管理系统都是好的应用实例。

在通讯服务系统上使用无密码认证会很奇怪，因为你将需要另外一个通讯系统来登录。你也不会让你的银行账户安全性唯一的依赖于你的Aol，尽管第二道身份识别过程会做补充。

当你在创建一个新的应用的时候可以考虑使用无密码方式，然而，更新一个已经存在并且有很多使用密码的用户的应用将面临许多问题，我建议同时使用两种登录方式而不是突然就切换为一种新的登录方式。把无密码认证作为一种选择，尤其是对于那些需要充值密码的用户，等几个月以后再通过评估来决定是否可行。

真实测试

我在一个新的客户端应用上使用无密码认证方式，这个应用给几百个内部员工和外部客户使用，这些人里面大约有一半具有好的IT技能并且每天都登录，所以他们的session很少过期，另外一半几乎都是一两个月才登录一次的管理人员，他们中许多人会忘记密码或拼错密码。

最大的问题：必须要让顾客深信这是安全的

“无密码”听起来不安全，并且很少有人在其他地方看到使用，我很幸运，那个客户端应用有一个科技悟性很强的并且理解这个观念的项目经理，即使在那时我已经同意如果有任何一点失败时可以添加密码。

从那个时候开始事情变得一帆风顺，由于技术上的原因，我不得不整合我自己的实现而不是依赖于第三方库。这个过程花了不到一天的时间，并且不需要再做密码管理——我们通常开发和测试的那些取哈希值、重置密码等没有意义的工作。

最大的额外好处：用户理解了无密码认证方式。这个过程很简单，但它是在各个阶段提供简单指示的最好方式。例如：

1．一个登录链接已经发送到您的邮箱，如果没有收到请检查一下垃圾邮件。

2.请点击这个链接来登录…您有10分钟时间在同一个浏览器中打开这个链接。

没有人感到困惑，没有人挣扎，没有人赞美这个系统但是也没有人抱怨，人们接受这个过程并且它也没有阻碍人们，跟密码相关的登录问题从三到四周每次减少到0。

结论

我不能声称无密码认证方式在哪都可以用，但是经验已经表明它绝对的正面。我是一个改变观念的人，从今以后所有我的应用都将是没有密码的，一些使用者可能会不高兴，但是我将仅仅在他们的登录表单中弹一个虚假的密码框并且忽视它。

原文链接：http://www.gbtags.com/gb/share/9521.htm