PART I: How To Log In [...

我们假设你已经知道如何建立一个登录+密码的HTML表单，并将其值传递给服务器端的一个脚本进行认证。下面的章节将讨论合理实用的认证模式，以及如何避免最常见的安全隐患。 要不要使用HTTPS？ 除非连接是安全的（即通过HTTPS隧道使用SSL/TLS），否则你的登录表单值将以明文形式发送，这使得任何在浏览器和Web服务器之间窃听的人都能够在他们通过时读取登录信息。这种类型的窃听是政府经常做的，但在一般情况下，我们不会解决'拥有'的电线，只是说这个。只要使用HTTPS。 从本质上讲，在登录过程中防止窃听/数据包嗅探的唯一实用的方法是使用HTTPS或其他基于证书的加密方案（例如，TLS）或经过验证& 测试的挑战-响应方案（例如，Diffie-Hellman-基于SRP）。任何其他方法都很容易被窃听的攻击者规避。 当然，如果你愿意变得有点不切实际，你也可以采用某种形式的双因素认证方案（例如，谷歌认证器应用程序，物理'冷战风格'密码本，或RSA密钥发生器加密狗）。如果应用得当，这甚至可以在不安全的连接下工作，但很难想象一个开发者会愿意实施双因素认证而不实施SSL。 （不要）使用自己的JavaScript加密/散列。 鉴于在你的网站上设置SSL证书的成本和技术难度（虽然现在可以避免）27，一些开发者倾向于推出自己的浏览器内散列或加密方案，以避免通过不安全的线路传递明文登录。 虽然这是一个崇高的想法，但它基本上是无用的（而且可能是一个安全缺陷），除非它与上述之一相结合--也就是说，要么用强大的加密技术保护线路，要么使用一个经过测试的挑战-响应机制（如果你不知道那是什么，只要知道它是数字安全中最难证明、最难设计和最难实现的概念之一）。 虽然对密码进行散列确实可以*有效地防止密码泄露，但它很容易受到重放攻击、中间人攻击/劫持（如果攻击者可以在你的不安全的HTML页面到达你的浏览器之前注入几个字节，他们可以简单地注释JavaScript中的散列），或暴力攻击（因为你把用户名、盐和散列的密码都交给攻击者）。 反人类的验证码 CAPTCHA是为了挫败一个特定类别的攻击：自动字典/暴力试错，没有人类操作。毫无疑问，这是一个真实的威胁，然而，有一些方法可以无缝地处理它，不需要验证码，特别是适当设计的服务器端登录节流方案--我们将在后面讨论这些。 要知道，验证码的实现并不一样；它们通常不是人类可以解决的，它们中的大多数对机器人实际上是无效的，它们对第三世界的廉价劳动力都是无效的（根据OWASP，目前血汗工厂的价格是每500次测试12美元），而且一些实现在某些国家可能在技术上是非法的（见OWASP Authentication Cheat Sheet）。如果你必须使用验证码，请使用谷歌的reCAPTCHA，因为根据定义，它是OCR-hard（因为它使用已经被OCR错误分类的书籍扫描），并且非常努力地做到用户友好。 就我个人而言，我倾向于认为验证码很烦人，只有在用户多次登录失败和节流延迟达到极限的情况下才会使用它们作为最后手段。这种情况很少发生，可以接受，而且它可以加强整个系统的功能。 存储密码/验证登录。 在我们近年来看到的所有高度公开的黑客攻击和用户数据泄漏之后，这可能最终成为常识，但它必须被说出来。不要在你的数据库中以明文方式存储密码。用户数据库经常被黑客攻击、泄露或通过SQL注入收集信息，如果你存储了原始的明文密码，那你的登录安全就会立即完蛋。 那么，如果你不能存储密码，你如何检查从登录表格中发布的登录+密码组合是否正确？答案是使用密钥推导函数进行散列。每当一个新的用户被创建或密码被更改时，你将密码通过KDF运行，如Argon2、bcrypt、scrypt或PBKDF2，将明文密码（"correcthorsebatterystaple"）变成一个长的、随机的字符串，这对于存储在数据库中来说要安全很多。为了验证登录，你在输入的密码上运行同样的哈希函数，这一次传入盐，并将得到的哈希字符串与存储在数据库中的值进行比较。Argon2、bcrypt和scrypt已经将盐与哈希值一起存储。查看sec.stackexchange上的这篇文章以获得更详细的信息。 使用盐的原因是，散列本身是不够的 -- 你想添加一个所谓的'盐'来保护散列的彩虹表。盐可以有效地防止两个完全匹配的密码被存储为相同的哈希值，防止攻击者在执行密码猜测攻击时一次扫描整个数据库。 加密哈希值不应该被用于密码存储，因为用户选择的密码不够强大（即通常不包含足够的熵），而且密码猜测攻击可以在相对较短的时间内由能够访问哈希值的攻击者完成。这就是使用KDF的原因--这些有效地"拉伸密钥"，这意味着攻击者的每一次密码猜测都会导致哈希算法的多次重复，例如10,000次，这导致攻击者猜测密码的速度慢了10,000次。 会话数据 - "你以蜘蛛侠69的身份登录"** 一旦服务器根据你的用户数据库验证了登录名和密码并发现匹配，系统需要一种方法来记住浏览器已经被验证。这一事实只能存储在服务器端的会话数据中。 如果你对会话数据不熟悉，这里是它的工作原理。一个随机生成的字符串被存储在一个即将到期的cookie中，用于引用存储在服务器上的数据集合--会话数据。如果你使用的是一个MVC框架，这无疑已经被处理了。 如果可能的话，确保会话cookie在发送给浏览器时设置了安全和HTTP Only标志。HttpOnly标志提供了一些保护，防止cookie被XSS攻击所读取。安全标志确保cookie只通过HTTPS发送回来，因此可以防止网络嗅探攻击。Cookie的值不应该是可预测的。如果出现一个引用不存在的会话的cookie，其值应立即被替换，以防止会话固定。

第二部分：如何保持登录状态--臭名昭著的"记住我"复选框

持续性登录Cookies（"记住我"功能）是一个危险区；一方面，当用户了解如何处理它们时，它们完全和传统的登录一样安全；另一方面，它们在粗心的用户手中是一个巨大的安全风险，他们可能在公共计算机上使用它们而忘记注销，而且他们可能不知道什么是浏览器Cookies或如何删除它们。 就我个人而言，我喜欢我经常访问的网站的持久性登录，但我知道如何安全地处理它们。如果你确信你的用户也知道这些，你就可以问心无愧地使用持久性登录。如果不是这样，那么你可以认同这样的理念：如果用户不小心使用他们的登录凭证，那么他们被黑客攻击就是咎由自取。我们也不可能到用户家里去撕掉他们在显示器边上贴的那些写有密码的便利贴。 当然，有些系统无法承受任何账户被黑；对于这样的系统，你没有办法证明有持久的登录。 如果你决定实施持久性登录cookies，你可以这样做：。 1.首先，花一些时间阅读Paragon Initiative'的文章，了解这个问题。你需要弄清楚一系列的要素，这篇文章对每个要素都做了很好的解释。 2.再重申一个最常见的陷阱，不要把持续的登录密码（TOKEN）存储在你的数据库中，只存储它的哈希值！**登录令牌等同于密码，所以如果攻击者拿到你的数据库，他们可以使用令牌登录到任何账户，就像他们是明文登录-密码组合一样。因此，在存储持久性登录令牌时，使用散列法（根据https://security.stackexchange.com/a/63438/5002，一个弱散列法就可以达到这个目的）。

第三部分：使用秘密问题

不要实现'秘密问题'。秘密问题的功能是一种安全反模式。请阅读必读列表中的第4个链接的论文。你可以问莎拉-佩林关于这个问题，因为她的雅虎电子邮件帐户在以前的总统竞选期间被黑了，因为她的安全问题的答案是..."Wasilla High School"! 即使有用户指定的问题，大多数用户也很可能选择其中之一。

• 一个'标准'的秘密问题，如母亲的婚前姓名或最喜欢的宠物
• 一个简单的琐事，任何人都可以从他们的博客、LinkedIn的资料或类似的资料中获得。
• 任何比猜测其密码更容易回答的问题。对于任何像样的密码，都是你能想象到的每一个问题。 **总之，安全问题在几乎所有的形式和变化中都是不安全的，不应该以任何理由在认证方案中采用。 安全问题存在于野外的真正原因是，它们可以方便地节省一些支持电话的费用，因为用户无法访问他们的电子邮件，无法获得重新激活的代码。这是以安全和萨拉-佩林的声誉为代价的。值得吗？也许不值得。

  PART IV: Forgotten Password Functionality 遗忘密码功能

  我已经提到了为什么你不应该使用安全问题来处理被遗忘/丢失的用户密码；同样不言而喻的是，你不应该把用户的实际密码通过电子邮件发给他们。在这个领域，至少还有两个非常常见的陷阱需要避免。 1.不要把忘记的密码重设为自动生成的强密码--这种密码是出了名的难记，这意味着用户必须改变它或者把它写下来--比如，写在显示器边缘的一张亮黄色的便利贴上。与其设置一个新的密码，不如让用户马上挑选一个新的密码--反正他们也想这么做。(如果用户普遍使用密码管理器来存储/管理密码，这可能是一个例外，如果不写下来，通常是不可能记住的）。 2.始终在数据库中对丢失的密码/令牌进行散列。AGAIN，这个代码是另一个密码等价物的例子，所以它必须被散列，以防攻击者得到他们的数据库。当请求丢失的密码代码时，将明文代码发送到用户的电子邮件地址，然后对其进行散列，将散列值保存在你的数据库中--并扔掉原件。就像密码或持久的登录令牌一样。 最后一点：一定要确保你输入'丢失的密码代码的界面至少和你的登录表格本身一样安全，否则攻击者会简单地使用它来获取访问权。确保你生成很长的'丢失的密码代码'（例如，16个区分大小写的字母数字字符）是一个良好的开端，但可以考虑添加与你对登录表格本身所做的相同的节流方案。

  ＃＃第五部分：检查密码强度＃＃。

  首先，你要读读这篇小文章，了解一下现实情况。500个最常见的密码。 好吧，也许这个名单并不是任何系统任何地方最常见的密码名单，但它很好地说明了在没有强制政策的情况下，人们会如何糟糕地选择他们的密码。此外，当你把这份名单与最近被盗的密码的公开分析进行比较时，它看起来非常接近家庭。 所以。在没有最低密码强度要求的情况下，2%的用户使用前20个最常见的密码之一。这意味着：如果攻击者只尝试了20次，那么你网站上每50个账户中就有1个是可以破解的。 挫败这种情况需要计算密码的熵，然后应用一个阈值。 国家标准与技术研究所（NIST）特别出版物800-63有一套非常好的建议。 当与字典和键盘布局分析相结合时（例如，'qwertyuiop'是一个糟糕的密码），可以拒绝99%的选择不佳的密码在18位熵的水平上。 简单地计算密码强度并向用户显示一个可视化的强度表是好的，但还不够。 除非它被强制执行，否则很多用户很可能会忽略它。 对于高熵密码的用户友好性，强烈推荐Randall Munroe的密码强度xkcd。 利用Troy Hunt的Have I Been Pwned API来检查用户的密码与公共数据泄露事件中的密码。

  第六部分：更多--或者：防止快速登录尝试

  首先，看一下这些数字。密码恢复速度--你的密码能支持多长时间 如果你没有时间去看那个链接中的表格，这里有它们的列表。 1.破解一个弱口令几乎不需要任何时间，即使你用算盘来破解它。 2.如果一个9个字符的字母数字密码是大小写不敏感的，那么破解它几乎不需要任何时间。 3.如果一个复杂的、符号-字母-数字、大写和小写的密码少于8个字符，那么破解它几乎不需要任何时间（一台台式电脑可以在几天甚至几小时内搜索到7个字符以内的整个按键空间）。 4.然而，即使是一个6个字符的密码，也需要花费大量的时间来破解，**如果你被限制在每秒钟一次的尝试！**。 那么，我们能从这些数字中学到什么？嗯，很多，但我们可以把重点放在最重要的部分：事实上，防止大量快速连续的登录尝试（即蛮力攻击）真的不难。但是，防止正确的并不像它看起来那么容易。 一般来说，你有三种选择，都能有效地防止暴力攻击（和字典攻击，但由于你已经采用了强密码政策，它们不应该成为问题）*。

• 在尝试N次失败后提出一个CAPTCHA（烦人得很，而且通常没有效果 -- 但我在这里重复自己的说法）。
• 锁定账户，并在N次尝试失败后要求电子邮件验证（这是一种等待发生的DoS攻击）。
• 最后，登录节流：也就是说，在N次失败的尝试之后，设置两次尝试之间的时间延迟（是的，DoS攻击仍然是可能的，但至少它们的可能性要小得多，而且实施起来也要复杂得多）。 最佳做法1：一个短暂的时间延迟，随着尝试失败次数的增加而增加，比如。
• 1次失败的尝试=没有延迟
• 2次失败的尝试=2秒延迟
• 3次失败的尝试=4秒延迟
• 4次失败的尝试=8秒延迟
• 5次失败的尝试=16秒延迟
• 等等。 对这种方案进行DoS攻击是非常不切实际的，因为所产生的锁定时间要比之前的锁定时间之和稍大。

  要澄清的是：延迟并不是*向浏览器返回响应前的延迟。它更像是一个超时或耐火期，在此期间，对一个特定账户或来自一个特定IP地址的登录尝试将完全不被接受或评估。也就是说，正确的凭证不会在成功登录时返回，而不正确的凭证也不会触发延迟增加。 最佳做法2：一个中等长度的延迟，在N次失败尝试后生效，比如。

• 1-4次失败的尝试=没有延迟
• 5次失败的尝试=15-30分钟的延迟 对这种方案进行DoS攻击是很不实际的，但肯定是可以做到的。另外，可能需要注意的是，这么长的延迟对合法用户来说是非常恼人的。健忘的用户会不喜欢你。 最佳做法#3：结合这两种方法--要么是一个固定的、短时间的延迟，在N次尝试失败后生效，比如。
• 1-4次失败的尝试=无延迟
• 5次以上失败的尝试=20秒延迟 或者，用一个固定的上限来增加延迟，比如。
• 1次失败的尝试=5秒延迟
• 2次失败的尝试=15秒延迟
• 3次以上失败的尝试=45秒延迟 这个最终方案来自OWASP的最佳实践建议（MUST-READ列表中的链接1），应该被认为是最佳实践，即使它被承认是在限制性的一面。 然而，作为一个经验法则，我想说的是：你的密码政策越强，你就越不需要用延迟来困扰用户。如果你要求强大的（大小写敏感的字母数字+必要的数字和符号）9个以上字符的密码，你可以在激活节流之前给用户2-4次非延迟的密码尝试。 DoS攻击这种最终的登录节流方案将是非常不切实际的。作为最后一点，总是允许持久性（cookie）登录（和/或验证码验证的登录形式）通过，所以合法用户甚至不会在攻击进行时被延迟。这样一来，非常不切实际的DoS攻击就变成了极端不切实际的攻击。 此外，对管理员账户做更积极的节流是有意义的，因为这些账户是最有吸引力的入口。

  第七部分：分布式暴力攻击 [PART VII: Distributed Brute Force Attacks] 。

  作为一个旁观者，更高级的攻击者会试图通过'传播他们的活动来规避登录节制。

• 在一个僵尸网络上分散尝试，以防止IP地址被标记
• 他们不会挑选一个用户并尝试50000个最常见的密码（由于我们的节流，他们不能这样做），而是挑选一个最常见的密码并对50000个用户进行尝试。这样一来，他们不仅可以绕过CAPTCHAs和登录节流等最大尝试措施，而且他们的成功机会也会增加，因为最常见的第一号密码远比第49.995号更有可能。
• 将每个用户账户的登录请求间隔开来，比如说，间隔30秒，以便在雷达下潜行。 在这里，最好的做法是记录整个系统的登录失败次数，并使用你的网站的错误登录频率的运行平均值作为你对所有用户施加的上限的基础。 太抽象了吗？让我重新表述一下。 假设你的网站在过去3个月中平均每天有120次不良登录。利用这个（运行的平均值），你的系统可能会将全局限制设置为这个数字的3倍--即在24小时内有360次失败尝试。然后，如果所有账户的失败尝试总数在一天内超过这个数字（或者甚至更好，监测加速率并在计算出的阈值上触发），它就会激活全系统的登录节流--意味着所有用户的短暂延迟（仍然，cookie登录和/或备份验证码登录除外）。 我还发布了一个问题，其中有更多的细节和关于如何避免棘手的陷阱的非常好的讨论在抵御分布式暴力攻击方面的问题

  第八部分：双因素认证和认证供应商

  凭证可能会被破坏，无论是漏洞、密码被写下和丢失、带钥匙的笔记本电脑被盗，还是用户在钓鱼网站上输入登录信息。 双因素认证可以进一步保护登录，它使用带外因素，如从电话、短信、应用程序或加密狗收到的一次性代码。一些供应商提供双因素认证服务。 认证可以完全委托给一个单点登录服务，由另一个供应商处理收集证书。这就把问题推给了一个受信任的第三方。谷歌和Twitter都提供基于标准的SSO服务，而Facebook则提供类似的专有解决方案。

  MUST-READ LINKS About Web Authentication ## 关于网络认证的链接

  1.OWASP认证指南 / OWASP认证小抄。 2.2. Dos and Don'ts of Client Authentication on the Web (very readable MIT research paper). 3.维基百科：HTTP cookie。 4.用于后备认证的个人知识问题。Facebook时代的安全问题（非常可读的伯克利研究论文） 5.

＃明确的文章

发送凭证

100%安全地发送凭证的唯一实用方法是使用[SSL][1]。使用JavaScript来哈希密码是不安全的。客户端密码散列的常见隐患。

• 如果客户端和服务器之间的连接是不加密的，你所做的一切都[容易受到中间人攻击][2]。攻击者可以替换传入的javascript以破坏散列或将所有凭证发送到他们的服务器，他们可以监听客户端的响应并完美地冒充用户，等等等等。使用受信任的证书颁发机构的SSL是为了防止MitM攻击。 *如果你不在服务器上做额外的、多余的工作，那么服务器收到的哈希密码就[不太安全][3]。 还有一种安全的方法叫SRP，但它是有专利的（尽管它是[免费授权][4]），而且很少有好的实现。

  存储密码

  永远不要把密码作为明文存储在数据库中。即使你不关心你自己网站的安全问题也不行。假设你的一些用户会重复使用他们网上银行账户的密码。因此，存储哈希密码，并扔掉原始密码。并确保该密码不会出现在访问日志或应用程序日志中。OWASP建议使用Argon2作为新应用程序的第一选择。如果没有这个，应该使用PBKDF2或scrypt来代替。最后，如果以上这些都不可用，就使用bcrypt。 哈希值本身也是不安全的。例如，相同的密码意味着相同的哈希值--这使得哈希查询表成为一次破解大量密码的有效方法。相反，存储盐的哈希值。盐是在散列之前附加到密码上的一个字符串--每个用户使用不同的（随机）盐。盐是一个公共值，所以你可以把它们和哈希值一起存储在数据库中。关于这一点，请看这里的详细信息。 这意味着你不能向用户发送他们忘记的密码（因为你只有哈希值）。不要重设用户的密码，除非你已经验证了用户的身份（用户必须证明他们能够阅读发送到存储（和验证）的电子邮件地址的电子邮件）。

  安全问题

  安全问题是不安全的 - 避免使用它们。为什么？安全问题的任何功能，密码都能做得更好。请阅读本维基中[@Jens Roland answer][6]的第三部分：使用秘密问题。

  Session cookies

  用户登录后，服务器会向用户发送一个会话cookie。服务器可以从cookie中检索到用户名或ID，但其他任何人都不能生成这样的cookie（TODO解释机制）。 [Cookie可以被劫持][7]：它们的安全性仅次于客户机的其他部分和其他通信。它们可以被从磁盘上读取，在网络流量中被嗅到，被跨站脚本攻击解除，从中毒的DNS中被钓鱼，这样客户就会把他们的cookie发送到错误的服务器。不要发送持久性cookies。Cookie应该在客户端会话结束时过期（浏览器关闭或离开你的域）。 如果你想让你的用户自动登录，你可以设置一个持久的cookie，但它应该与全会话cookie不同。你可以设置一个额外的标志，即用户已经自动登录，在敏感操作中需要真正登录。这在希望为你提供无缝、个性化的购物体验，但仍然保护你的财务细节的购物网站中很受欢迎。例如，当你返回访问亚马逊时，他们会向你展示一个看起来像你已经登录的页面，但当你去下订单（或改变你的送货地址、信用卡等）时，他们会要求你确认你的密码。 另一方面，银行和信用卡等金融网站只有敏感数据，不应允许自动登录或低安全模式。

  外部资源列表

• [Dos and Don'ts of Client Authentication on the Web (PDF)] (http://pdos.csail.mit.edu/papers/webauth:sec10.pdf) 21页的学术文章，有许多很好的提示。
• Ask YC: Best Practices for User Authentication 关于该主题的论坛讨论
• 你可能是在错误地存储密码](http://www.codinghorror.com/blog/archives/000953.html) 关于存储密码的介绍性文章
• 讨论。恐怖的编码。你很可能是在错误地存储密码 关于Coding Horror文章的论坛讨论。
• [永远不要在数据库中存储密码！](

首先，强烈告诫大家，这个答案并不是这个确切问题的最佳答案。它绝对不应该是最重要的答案!

我将继续提到Mozilla提出的BrowserID（或许更确切地说，是验证电子邮件协议），以找到未来更好的认证方法的升级路径。

我将这样总结一下。

1.Mozilla是一个非营利组织，它的价值观与寻找这个问题的良好解决方案非常一致。 2.今天的现实是，大多数网站都使用基于表单的认证。 3.基于表格的认证有一个很大的缺点，那就是增加了网络钓鱼的风险。用户被要求将敏感信息输入一个由远程实体控制的区域，而不是由其用户代理（浏览器）控制的区域。 4.4.由于浏览器是隐含的信任（用户代理的整个想法是代表用户行事），它们可以帮助改善这种情况。 5.阻碍进展的主要力量是部署僵局。解决方案必须被分解成若干步骤，这些步骤本身就能提供一些递增的好处。 6.6. 最简单的表达身份的去中心化方法是域名，它被建在互联网基础设施中。 7.7. 作为表达身份的第二层次，每个域名都管理着自己的一套账户。 8.8. "account@domain "的形式是简明的，并得到广泛的协议和URI方案的支持。当然，这样的标识符最普遍地被认为是一个电子邮件地址。 9.9. 电子邮件供应商已经是网上事实上的主要身份提供者。目前的密码重置流程通常让你控制一个账户，如果你能证明你控制该账户的相关电子邮件地址。 10.10. 提出验证电子邮件协议是为了提供一种基于公钥密码学的安全方法，以简化向域名B证明你在域名A上有一个账户的过程。 11.11.对于不支持验证邮件协议的浏览器（目前所有的浏览器），Mozilla提供了一个垫片，在客户端的JavaScript代码中实现了该协议。 12.对于不支持验证电子邮件协议的电子邮件服务，该协议允许第三方作为一个可信的中介，断言他们已经验证了用户对账户的所有权。拥有大量这样的第三方是不可取的；这种能力只是为了允许一个升级路径，而且更倾向于由电子邮件服务自己提供这些断言。 13.13. Mozilla提供了他们自己的服务，就像这样一个受信任的第三方。实施验证邮件协议的服务提供商（即信赖方）可以选择是否信任Mozilla的断言。Mozilla的服务使用传统的手段，即发送带有确认链接的电子邮件，来验证用户的账户所有权。 14.14. 当然，服务供应商可以在他们可能希望提供的任何其他认证方法之外，将该协议作为一个选项。 15.15. 这里寻求的一个重要的用户界面好处是 "身份选择器"。当用户访问一个网站并选择认证时，他们的浏览器会显示他们选择的电子邮件地址（"个人"、"工作"、"政治活动 "等），他们可以用这些地址向该网站表明自己的身份。 16.作为这项工作的一部分，正在寻求的另一个大的用户界面好处是帮助浏览器了解更多关于用户的会话 - 他们目前主要以谁的身份登录 - 所以它可以在浏览器的chrome中显示。 17.由于这个系统的分布式性质，它避免了对主要网站的锁定，如Facebook、Twitter、谷歌等。任何个人都可以拥有自己的域名，因此可以作为自己的身份提供者。

这不是严格意义上的 "基于表单的网站认证"。但它是一种努力，从目前基于表格的认证规范过渡到更安全的东西：浏览器支持的认证。