用户名 + 密码 = 危险。

自白

我是一名业余菜鸟黑客。

我业余到什么程度呢？

我连代码都不会敲，我没考上大学，只是看过几本黑客的书算作入门，混过黑圈打过酱油。开始我还会觉得会自卑，毕竟是想混传说中精英荟萃的黑客圈。但不久后我发现，大多数黑客们，都和我一个德性。

只通过市场上能够购买到，甚至免费使用的工具，我已经成功攻破了一千三百多个网站的用户系统，获取到上千万条用户名和密码信息。将这些信息卖掉，我下半生衣食无忧。

网络上遍布了无数的「豆腐渣工程」。

感谢这些开发者们，感谢这些工程，感谢你们。

---

老生谈新事

对于唱衰用户名+密码身份验证的文章屡见不鲜，但是所有主流的互联网产品，仍然在使用着这一传统但有效的验证系统。

我周围有两种人，一种对于身份安全毫无理解、毫无意识，他们会在各种网站上用最简单易记的同一组用户名与密码（他们也没有辨别钓鱼网站的能力）；另一种则紧张兮兮、小心翼翼，惊弓之鸟们不一定会有足够的信息安全知识，但是已经被各种新闻和话语搞得紧张兮兮，他们使用各种类似LastPass、1Password等身份管理工具来帮助他们管理无数条身份数据。

但是，就算是使用了这些密码管理工具，也不过是在试图延长「用户名+密码」这种身份认证方式的存在时长罢了。未来渴求着更便捷安全的方式。用户安全已经不能再用用户名+密码来保障了。

至少，不能只用用户名+密码。

温柔的密码

开发者们都知道，大多数的密码存放都是通过哈希算法，将密码转化成没人看得懂也无法还原回去的一段信息，存储在数据库里。当需要验证密码是否有效的时候，会将刚输入的密码用同样方式转化，用这个结果与存储的结果比对。也就是说，数据库内不会存放真正的密码信息，无法找回、无法读取。

相比于很多年前很多密码直接明文存放在数据库内的做法，这种方式无疑可靠了非常多。但是这种方式又依赖于所使用的哈希算法的有效性。

例子

我举一个很常见的例子：一个用户的密码为 ILoveJGSH@2017 ，开发者将密码使用 MD5 进行哈希计算后存储到数据库内。这个密码的长度不短，和大家日常用的密码相比，强度也不低。MD5也是开发者们非常广泛采用的哈希算法。

在整个黑客破解过程中，有两个因素决定了某一个密码（比如我自己的密码）能否被破解成功：密码强度和算法强度。密码越复杂越随机，算法强度越高、措施使用越得当，就越难还原。

在上面举例的情境中，破解弱点如下：

1. MD5哈希算法有漏洞。从二十余年前起，几乎每年都有新的MD5算法漏洞或者弱点被发现，直到2010年，位于卡内基梅隆大学的「软件工程机构」宣布：MD5算法 "cryptographically broken and unsuitable for further use" [1, Dougherty] (笔者译:密码学角度上已被攻破，不适合继续使用)，应该使用SHA-2家族哈希算法替换。

2. 密码强度不够。这个密码的长度是合格的，超出大多数系统内密码最低要求和平均值，也包含大小写字母、数字和特殊字符，在同时尝试破译成千上万个哈希后密码的时候，黑客不会有充足的时间针对其中一个进行特殊进攻。在这种情况下，这个密码很难被破解。但是如果有时间或有目的地只向着一个密码专门进攻（比如某个有特别价值的账号，某个富豪、或者某个公司的财会或IT账号），我们可以看到前九位都是字母，特殊字符@后面都是数字，前五位是英文ILove，后四位是当前年份。这些常见规律会极大地降低密码分析的难度，从而使得解码变为可能。

我曾经做过一个实验，（合法但不为人知地）获取到了某一个用户系统内的五千余条真实的用户信息（用户名+哈希过后的密码），使用了某个在网上可以下载到的黑客哈希破解工具，在一个半小时内将超过半数的密码破解掉，其中包括abc123或者root这种低安全等级密码，也包括类似alice_lee007，AllHailNY1这种可能看似足够安全的密码。

整个破解过程中几乎不需要任何专业知识，只需要知道怎么用几个工具而已。

针对薄弱的哈希算法，我们可以使用更强力的哈希工具替换，但是仍然不能完全保证不被破解。

真实的黑客破译方式是多元的，比如一个弱密码使用任何哈希算法都不能防御彩虹表进攻。而且，上面例子中的两个弱点指的只是解码过程中的弱点，还没有算传输过程中可能的弱点、中间人进攻、中途相遇进攻、钓鱼进攻、病毒木马进攻、跨域脚本进攻等等防不胜防的进攻方式，甚至用户自己也会把密码写在某个公开的位置（纸上、文件里、借给别人用）。如果能通过别的方式直接获取到密码，那么甚至连解码都不需要了。

而如果想要增强密码强度，我们可以来看看一个真正的强密码的例子，由LastPass软件生成：

强密码举例：hzMVX*4AjPve9skC

完全无法记忆，没有任何规则，长度16位，包括随机数量的大小写字母、数字和特殊字符。只有在这种清下，黑客才会被迫和算法本身硬碰硬。有迹可循的密码同时也让黑客有迹可循。

好记的密码，同时意味着更容易被破解。

大家可以比对一下，自己最常用的密码，到底是属于强密码范畴，还是属于刚才例子中会被我轻松破解的范畴。如果你想每个应用都换个不同的强密码的话，那么记忆将完全不可能，只能使用工具代为辅助。

50个最常用的密码

上图摘自wpengine.com，他们选取了一千万个密码并做了详尽的数据分析，可以明显看出，大多数用户都使用了非常弱的密码，绝大多数用户对于身份安全几乎没有任何理解或防范。链接在此：Unmasked: What 10 million passwords revealabout the people who choose them 。

不完整的救星

针对这种解码方式，最直接的对抗者就是加「盐」。在密码中添加一段随机字符叫做「盐」，然后再通过哈希算法计算。这样得出的结果，就算是两个完全相同的密码，由于「盐」不一样，结果也会南辕北辙。

如果你开发的网站或使用的网站恰当地使用了加「盐」，那么你的用户密码安全就比其他网站都会更胜一筹。

但是，每当引入一种新的安全机制的时候，就会同时衍生出各种新的进攻点。如果一个用户的「盐」被获知，就会极大地降低解码的复杂度。保护「盐」又成了关键的任务。

针对加盐密码哈希的弱点和攻防，这里有一篇由 伯乐在线 翻译的非常专业的普及文章，如果希望了解更多看更多例子，或者对密码安全的复杂度认识不够的话，请看：「加盐密码哈希：如何正确使用」。

然而就算是使用了最最专业的密码保护措施，把自己的用户密码保护地像一座堡垒一样万夫莫开，也有一个最最关键、却又没有解决的问题：

在不断的攻防之中，我们可以把一个系统保护地固若金汤，但是我们没有办法保护别人的系统。在70%用户在多个网站使用同一个密码的情况下，如果攻破了别的网站，也就相当于攻破了你的。无论你使用了怎样的保护机制，如果只有用户名+密码，那么就会形同虚设。

在用户名+密码的安全系统内，这个问题无解。

这是用户名+密码的最大限制和最大威胁，也是得出「不安全」结论的致命一击。

在国外，已经有80%的人对他们的在线身份安全感到忧虑，同时有超过70%的人认为用户名+密码的方式不足够保障身份安全。[2, OKyle] 

多因素认证（Multi-Factor Authentication）

阿里云在用、淘宝在用、百度在用、腾讯在用、魔兽世界已经用了十几年、微博微信都在用，Twitter在用，Apple 在用，Google、微软、 Facebook、 亚马逊 已经沿用很久。什么是多因素认证？

救星来了。

如果单纯的用户名+密码不足够安全的话，那么就再添加一层认证就好了。这种多重认证方式叫做：「多因素认证」。也叫多重认证。当认证次数为二的时候，也叫二次认证、二次验证等等。

在支付宝进行支付的时候，会要你在已经登录的情况下输入六位支付密码，并且会确认「安全环境」；在ATM取款机前，你需要同时插入正确的卡片和输入正确的口令；在使用用户名+密码登录微信公众号之后，会弹出需要使用微信扫码才能继续访问的界面。在试图修改阿里云服务器的安全组的时候，可能会发送验证码到你的绑定手机号；电影大片中开门使用的指纹、虹膜和密码三位一体……

短信验证码示例

虽然「多因素认证」这个名字仍显生疏，但无论是开发者还是用户，已经早已离不开它的保护。

只要一个账号有价值，它就应该（或者已经）被多因素验证保护起来。

想象一下，有多少黑客你可以在远程黑掉你的用户名和密码信息的同时，还能走到你面前抢走你的手机、U盾，或者同时盗用你的邮箱或者指纹？

几乎不可能有。

如果没有多因素认证，遇到用户名密码泄露，用户信息就赤身裸体地等着不法人员去翻看。而有多因素认证的保护，尴尬的就该是黑客了。没有多因素认证保护的用户系统，绝对不会是一个安全的产品，也就是网络中的「豆腐渣工程」。

网络中的「豆腐渣工程」和现实中的「豆腐渣工程」非常相似：表面看上去毫无问题、需要专业人员才能为其检测定性、非安全相关人员几乎没有能力去辨别，但是一旦有任何风吹草动、黑客攻击或地震泥流，二者都同样会崩溃。人们、甚至包括被蒙在鼓里的项目负责人，才会发现安全问题的重要性。

而到那时，损失已成，媒体曝光，悔之晚矣。

「豆腐渣工程」：是指那些由于偷工减料等原因造成不坚固的危险容易毁坏的工程。 （百度百科）
网络中的「豆腐渣工程」：是指那些由于缺乏必要安全知识、或由于为了减少研发开支等原因造成的有可怕安全风险的容易被攻破的网络工程。

我们日常中最常见到的二次认证认证，在国内是由手机验证码实现的，在国外是由邮箱实现的。这两种方式做到的都是同一个事情，都是在已经确认了用户名和密码的情况下，再次从另外一个维度去验证你的身份：确认你拥有绑定的手机、确认你拥有绑定的email。

然而，真正的多因素认证，可以在维持安全性的情况下，远远比上面的例子更加灵活。我们来看多因素认证的定义：

Multifactor authentication (MFA) is a security system in which more than one form of authentication is implemented to verify the legitimacy of a transaction. [3, Mohamed]

笔者译：多因素认证是一种使用多于一种认证元素来验证当前操作合法性的安全机制。

多因素认证的安全性取决于两个方面：

其一，单个因素的强度。我们很难说手机上的指纹认证肯定会比用户名密码更安全，但是我们知道密码越长越复杂随机就越安全，不联网的硬件比互联网上安全等等；

其二，两个元素之间的隔离度。在非法获取了一个因素的同时，是否更容易获取另外一个因素，越不容易，隔离度就越好，安全性就越高。在获取到了手机的时候，如果二次认证使用的是验证手机号码+手机指纹的话，很明显就不如验证手机号码+用户名密码安全，因为获得到了手机的时候，手机指纹的破解难度会急剧降低，但破解用户名密码的难度可能不变。

在铭记这两点的时候，我们可以随意前后打乱我们希望实现的二次认证中的两个「因素」。不一定要先使用用户名+密码进行验证之后再发送验证码到绑定的手机号上。

目前最常见的二次认证，是用户名+密码再加上这些验证方式的一种：第二个密码、手机号验证、邮箱验证、手机App验证。这之中最常见的是手机号验证，在企业中常用的是手机App验证。

手机号验证的好处很多：最宽广的用户覆盖、用户没有任何使用成本、已经成熟的不用学习的使用方式。而且对很多开发者/应用拥有者来讲，很关键的一点是：可以获得到真实的可以联系到的用户手机号，并且向用户随时发送消息。

缺点也很明显：
1. 收费。一天如果发1W条的话，按照市面上最便宜的提供商，开支就是10,000条/天 * 0.04元/条 * 30天 = 12,000元/月，十分可观。
2. 速度不稳定。有多少次你在登录或者注册的时候拿着手机静静等待着不知道什么时候会收到的手机短信？
3. 用户使用不顺畅。又有多少次你一个数字一个数字地确认自己没有输入错误？

而手机App的优缺点也很明确：没有短信费用，用户使用简便（可以不输入数字，只按确认按钮，甚至某些机型可以做到无感知验证），但是有一个巨大的缺点：用户需要下载一个应用。这就是为什么在企业中这种方式可以得到推行，但是在面向普遍用户的时候，手机App的推行会很困难的原因——短信功能谁都有，手机App可不一定。对于面向大众的服务，每一次身份验证都会有或多或少的用户流失，而如果让用户下载一个App专门验证的话，可能用户就因此而放弃使用整个服务了。

然而，在国内大行其道的目前还是针对大众的应用，针对企业的服务还仍然处于萌芽成长期。

我自己负责开发过的多个产品，大多也是面型大众用户的，在我为它们设计二次认证系统的时候，我一直在寻求一种更加完美的方法。

有没有什么方法，能够降低短信验证码的成本，同时拥有不逊于手机短信的覆盖率？能够避免输入错验证码，或者干脆无须输入验证码，同时还能够确保身份验证的即时性，无须等待？

有没有办法把手机App验证和短信验证的优点结合起来？

或者换个问法，有没有哪个应用，覆盖率足够广，人人都有都会常用，并且有足够的开发者权限允许进行二次开发？

答案呼之欲出。

微信。

微信

使用 微信 的二次认证利弊

使用微信做二次认证的优点：
1. 覆盖面极广。你的目标用户中会有多少希望使用你的应用，但是不使用微信的？
2. 无需安装。相比于一个需要下载一个新的App来做专门的认证而言，使用已有的无疑对最终用户来讲是个福音。
3. 无须教学。相比于一个新的App，用户需要时间和精力去学习、尝试才能掌握。但是人人都已经熟悉微信扫码的功能。
4. 极低成本。除去开发费用外，只有网络通讯费用，没有每条短信的费用。将通讯商从流程中剔除掉，可以极大降低成本。
5. 稳定的速度。和网速直接挂钩，在大多数网络通畅的地方，无须等待，扫码即过，畅行无阻。极大优化用户体验。
6. 无须输入。用户不用再小心地输入验证码。验证码的作用本身就是验证用户拥有该手机号，使用微信后可以做到类似手机App认证的体验，扫码直接验证。

有利就有弊。

1. 依赖网络。微信的速度依赖于网络，如果你的用户经常出现在没有网络的地方，那么微信的速度可能还没有短信快。在安全级别非常高的系统中，微信的可用性值得考量。
2. 无法获取用户的联系方式。在只需要身份验证的情况下，联系方式拿来是没有用处的。有的系统需要给用户发送提醒，比如支付、转账、密码修改等等，微信不能灵活地联系用户。使用微信服务号会有很大帮助，但仍然做不到手机号码一样灵活。

我们可以看出来，在用户联网状态，在应用开发者不需要向对方主动发起联系的情况下，微信的优势非常明显。

开发有多困难？

开发完整安全的手机验证码二次认证系统不仅仅是一个简单的调用一个发送消息接口并检查验证码那么简单。开发利用微信的二次认证也不是，有非常多的附加功能需要开发，让这个系统变得完善好用。我可以随便举些例子：

1. 需要数据库记录每次验证尝试，可以追溯什么人在什么时间做了什么验证。
2. 可以验证时记录IP、地理位置、使用时间、浏览器型号等等，以此为据来进行更多角度验证。
3. 在验证过后一定时长内可以不用重复验证。
4. 需要用户有绑定微信的入口和服务器机制。
5. 需要提供用户解绑微信并绑定新微信的机制。
6. 需要在用户微信失效、换手机、换号码、没有网络链接等情况下提供备用验证方式。

7. 如果使用微信开放平台的话，需要认证费用每年300元，需要提供各种验证资料，并有至少数天的审核时间。
8. 如果使用微信公众平台的话，需要认证费用每年300元，除了认证审核外，还需要实现你自己的WebSocket机制和多个前端、手机端流程页面。
………………

这列举出来的功能之中，前六个是几乎所有二次认证系统都会需要的，而7、8针对的是微信二次认证的集成。集成完整一整套的二次认证系统，在顺利的情况下，也会需要几十个工时的时间。

如果你的团队有人有钱有时间精力，那自然不在话下。但是对于非常多的创业型项目、外包型项目和一些定制项目，我们会追求速度，追求低成本，追求快速迭代试错。很可能一个月甚至一两周就可以出现一版产品的情况下，花费大把的时间在一个与产品业务几乎没有任何关系的「二次认证」上，就显得难以接受了。然而，安全系统是与产品业务系统同枝共长的，如果等到产品发展起来后再考虑安全，成本将会指数提高。

搜遍网络，在国外有Authy，Duo这种成熟的二次认证服务提供给大众和企业用户，但是在国内，还是一片空白。开发者想要实现自己系统内的多因素认证，就只能漫道真如铁，迈步从头越。甚至任何关于如何搭建二次认证系统的信息都搜索不到。而没有可用服务的现实，直接导致了非常多的用户系统不会使用足够的安全手段去保护。

想象一下软件和网络正在如何改变你的生活，你的网络身份究竟有多重要，就可以发现开发者对于身份安全有巨大的知识漏洞。

百度搜索结果 「开发 二次认证」

在 2017 年美国 Verizon 信息泄露事故报告中，超过80%的成功黑客行为是基于薄弱、默认或者被盗窃的密码。[4, Duo Security] 而多因素认证，是最直接、最简单干脆能够抑制住这种极其普遍且极易造成巨大危害病因的良药。

传统的二次认证服务提供方普遍有着普通企业根本无法支付的开销、上世纪80年代古老的用户体验和界面，和极其复杂的安装部署流程，导致了企业和开发者们对购买、集成和维护的强烈抗拒。

但是在任何情况下这都不足以构成忽略基础安全的借口。

我诚恳地希望产品负责人们、开发者和用户们都可以意识到网络「豆腐渣工程」的危害，并将一些基本的安全保护措施从一开始就设计进系统中，以免黑客从你们的钱包和信誉中获利。

「安全第一」这个口号，终究要喊到网络中来。

轻锁 微信二次认证 服务

作为互联网安全公司的一员，我借助公司团队开发了一款微信二次认证的工具，叫做 轻锁 。轻锁的最终目的是帮助开发者管理、维护并设计出安全的用户身份系统，虽然目前只提供微信验证的功能，但是会逐步添加各种面向开发者的安全服务，并逐渐成一个支持各种认证方式、支持内外网并提供所有相关功能的身份认证服务。轻锁设计的最关键理念，除了安全本身，就是快捷。用户使用快捷通畅，开发者集成快捷无阻。希望 轻锁 能在设计用户系统时，给开发者们提供一个安全快捷的选项。

如果你是一家企业并有更加广泛的身份安全需求，可以直接联系我所在的公司 北京九州云腾 或致电 010-58732285，我们的产品包括了身份、认证、授权、审计、应用单点登录、数据安全交换、扫码登录、二次认证等等一整套的企业身份安全服务体系。

世界正在被网络转化中，而所有的系统、网络、应用的关卡和门锁，就是身份验证。身份安全的重要性一再被提及，也一再被忽略。

世界需要的从来都是推波助澜，而不是随波逐流。

九州云腾 Michael

---

引用（References）：

1. Chad R, Dougherty (Dec 31 2008). Vulnerability Note VU#836068 MD5 vulnerable to collision attacks, Vulnerability notes database. CERT Carnegie Mellon University Software Engineering Institute. Retrieved3 February2017., https://www.kb.cert.org/vuls/id/836068
2. Okyle, Carly (June 3 2015). Password Statistics: The Bad, the Worse and the Ugly (Infographic), https://www.entrepreneur.com/article/246902
3. Mohamed, Tamara Saad (2014) , Security of Multifactor Authentication Model to Improve Authentication Systems, ISSN 2224-5758 (Paper) ISSN 2224-896X (Online), Vol.4, No.6, 2014, http://www.iiste.org/Journals/index.php/IKM/article/viewFile/13871/13939