第一部分：如何登录
我们假设您已经知道如何构建一个登录名+密码HTML表单，该表单将值发布到服务器端的脚本中以进行身份验证。以下各节将介绍合理的实用身份验证模式，以及如何避免最常见的安全陷阱。
要HTTPS还是不要HTTPS？
除非连接已经安全（即使用SSL / TLS通过HTTPS进行隧道连接），否则您的登录表单值将以明文形式发送，这使任何窃听浏览器和Web服务器之间链接的人都可以在通过时读取登录信息通过。这类窃听通常由政府执行，但总的来说，除了说这句话外，我们不会处理“自有”的窃听器：仅使用HTTPS。
本质上，防止登录期间窃听/数据包嗅探的唯一实用方法是使用HTTPS或其他基于证书的加密方案（例如TLS）或经过验证的测试挑战响应方案（例如Diffie-Hellman）的SRP）。窃听攻击者可以轻松地绕过任何其他方法。
当然，如果您有点不切实际，也可以采用某种形式的两因素身份验证方案（例如Google Authenticator应用，物理“冷战风格”密码本或RSA密钥生成器加密狗）。如果正确应用，即使在不安全的连接下也可以使用，但是很难想象开发人员愿意实施两因素身份验证而不是SSL。
（请勿）自行编写JavaScript加密/哈希
考虑到（虽然现在可以避免）的成本以及在您的网站上设置SSL证书的技术难度，一些开发人员倾向于使用自己的浏览器内哈希或加密方案，以避免在不安全的网上传递明文登录信息。
尽管这是一个高尚的思想，但是除非与以上内容之一结合使用，否则它基本上是没有用的（并且可能是安全缺陷）-也就是说，要么通过强加密保护线路，要么使用经过验证的挑战响应机制（如果您不知道这是什么，只需知道它是数字安全中最难证明，最难设计和最难实现的概念之一）。
散列密码确实可以有效地防止密码泄露，但是它很容易受到重放攻击，中间人攻击/劫持（如果攻击者可以在不安全的HTML页面中注入一些字节，然后再到达您的网站）浏览器，他们可以简单地注释掉JavaScript中的哈希）或蛮力攻击（因为您同时向攻击者提供了用户名，盐和哈希密码）。
CAPTCHAS反人类
CAPTCHA旨在阻止一种特定的攻击类型：无需人工操作的自动词典/蛮力试错法。毫无疑问，这是一个真正的威胁，但是，有许多方法可以无缝处理它，不需要验证码（经过专门设计的服务器端登录限制方案），我们将在后面讨论。
知道CAPTCHA的实现不是完全一样的。它们通常不是人类可以解决的，大多数实际上对机器人无效，对廉价的第三世界劳动力而言它们都是无效的（根据OWASP，当前的血汗工厂收费标准是每500个测试12美元），某些实现可能是在某些国家/地区在技术上是非法的（请参阅OWASP身份验证备忘单）。如果必须使用CAPTCHA，请使用Google的reCAPTCHA，因为从定义上讲它是OCR硬的（因为它使用了已经被OCR误分类的书本扫描），并且会尽力使用户友好。
就个人而言，我倾向于发现CAPTCHAS令人讨厌，并且仅在用户多次登录失败且限制延迟已达到最大时才将其用作最后的手段。这种情况很少发生，无法接受，并且会增强整个系统。
存储密码/验证登录名
在近年来发生的所有广为人知的黑客和用户数据泄漏之后，这可能最终成为常识，但是必须指出：不要在数据库中以明文形式存储密码。用户数据库通常会通过SQL注入被黑客入侵，泄漏或收集，如果您存储的是原始的纯文本密码，那么对于登录安全性来说，这是即时游戏。
因此，如果您不能存储密码，如何检查从登录表单中过帐的登录名和密码组合是否正确？答案是使用密钥派生函数进行哈希处理。每当创建新用户或更改密码时，您都将获取密码并通过KDF（例如Argon2，bcrypt，scrypt或PBKDF2）运行它，将明文密码（“ correcthorsebatterystaple”）变成一个长的，随机的字符串，这样可以更安全地存储在数据库中。为了验证登录名，您对输入的密码运行相同的哈希函数，这次传入了salt并将结果哈希字符串与数据库中存储的值进行比较。Argon2，bcrypt和scrypt已经将盐与哈希一起存储。请查看sec.stackexchange上的本文以获取更多详细信息。
使用盐的原因是散列本身是不够的-您将要添加一个所谓的“盐”来保护散列免受彩虹表的侵害。Salt可以有效地防止将两个完全匹配的密码存储为相同的哈希值，从而防止在攻击者执行密码猜测攻击时一次扫描整个数据库。
密码哈希不能用于密码存储，因为用户选择的密码不够强（即通常不包含足够的熵），并且攻击者可以在较短时间内完成对密码的猜测攻击。这就是为什么使用KDF的原因-这些有效地“拉伸密钥”，这意味着攻击者猜测的每个密码都会导致哈希算法的多次重复，例如10,000次，这会使攻击者猜测密码的速度慢10,000倍。
会话数据-“您以Spiderman69登录”
服务器针对您的用户数据库验证了登录名和密码并找到匹配项后，系统需要一种方式来记住浏览器已通过身份验证。这个事实只应该存储在会话数据的服务器端。
如果您不熟悉会话数据，请按以下说明进行操作：将一个随机生成的字符串存储在到期的cookie中，并用于引用存储在服务器上的数据集-会话数据。如果您使用的是MVC框架，那么无疑已经进行了处理。
如果有可能，请确保会话cookie发送到浏览器时已设置了安全和HTTP Only标志。HttpOnly标志为通过XSS攻击读取cookie提供了一些保护。安全标志可确保Cookie仅通过HTTPS发送回，因此可以防止网络嗅探攻击。cookie的值不应是可预测的。如果提供了引用不存在的会话的cookie，则应立即替换其值以防止会话固定。
第二部分：如何保持登录状态-臭名昭著的“记住我”复选框
永久登录Cookie（“记住我”功能）是一个危险区域；一方面，当用户了解如何处理它们时，它们与传统登录完全一样安全；另一方面，粗心的用户则面临巨大的安全风险，他们可能会在公用计算机上使用它们，却忘记了注销，并且可能不知道浏览器cookie是什么或如何删除它们。
就个人而言，我喜欢经常访问的网站的永久登录，但是我知道如何安全地处理它们。如果您确定用户知道相同的信息，则可以凭良心使用持久性登录。如果不是-很好，那么您可能会赞同这样一种哲学，即粗心的登录凭据的用户会在被黑客入侵时将其带到自己身上。这也不像我们去用户家并撕下所有由facepalm引发的Post-It便条一样，它们的密码也都已排列在显示器的边缘。
当然，某些系统承受不了任何帐户被黑客入侵的风险。对于此类系统，您无法证明拥有永久登录名是合理的。
如果您决定实施永久性登录cookie，请按以下步骤进行：
首先，花一些时间阅读Paragon Initiative关于该主题的文章。您需要正确处理一堆元素，并且本文在解释每个元素方面做得很好。
只是要重申最常见的陷阱之一，请勿将持久登录的Cookie（令牌）存储在您的数据库中，而只是将其作为哈希！登录令牌是等效的密码，因此，如果攻击者将您的手放在您的数据库上，他们可以使用令牌登录任何帐户，就像它们是明文登录密码组合一样。因此，在存储持久性登录令牌时，请使用哈希（根据https://security.stackexchange.com/a/63438/5002进行此操作，散列就可以达到目的）。
第三部分：使用秘密问题
不要实施“秘密问题”。“秘密问题”功能是一种安全反模式。从必读列表中的链接编号4中阅读论文。您可以在Yahoo!之后询问Sarah Palin的问题。该电子邮件帐户在上次总统竞选期间遭到黑客入侵，原因是对她的安全性问题的回答是“ Wasilla高中”！
即使有用户指定的问题，大多数用户也很可能会选择以下任一项：
总而言之，安全性问题本质上在所有形式和变体上本质上都是不安全的，并且出于任何原因都不应在身份验证方案中使用。
甚至在野外还存在安全性问题的真正原因是，它们可以方便地节省一些无法访问其电子邮件以获取重新激活码的用户的一些支持电话的费用。这是以牺牲安全性和萨拉·佩林的声誉为代价的。值得？可能不是。
第四部分：忘记的密码功能
我已经提到了为什么您永远不应该使用安全性问题来处理忘记/丢失的用户密码。不用说，您永远不要通过电子邮件向用户发送其实际密码。在此字段中，至少要避免两个非常常见的陷阱：
不要将忘记的密码重设为自动生成的强密码-众所周知，此类密码很难记住，这意味着用户必须更改密码或将其写下来-例如，在显示器边缘的亮黄色Post-It上。无需设置新密码，只需让用户立即选择一个新密码即可。（这可能是一个例外，如果用户普遍使用密码管理器来存储/管理通常不记下来就无法记住的密码）。
始终对数据库中丢失的密码代码/令牌进行哈希处理。再次，此代码是等效密码的另一个示例，因此必须进行哈希处理，以防攻击者使用您的数据库。当要求输入丢失的密码代码时，请将纯文本代码发送到用户的电子邮件地址，然后对其进行哈希处理，然后将哈希表保存在数据库中，然后丢弃原始密码。就像密码或永久登录令牌一样。
最后一点：请始终确保您输入“丢失的密码”的界面至少与登录表单本身一样安全，否则攻击者只会使用它来获取访问权限。确保您生成非常长的“丢失的密码”（例如，区分大小写的16个字母数字字符）是一个很好的开始，但是请考虑添加与登录表单本身相同的限制方案。
第五部分：检查密码强度
首先，您需要阅读这篇小文章进行现实检查：500个最常用的密码
好吧，也许该列表是不规范的最常见的密码列表上的任何系统的任何地方不断，但它的人多么糟糕会选择自己的密码时，有一个地方不执行政策一个很好的迹象。此外，将列表与最近对被盗密码进行公开分析相比，该列表看上去离家很近。
因此：在没有最低密码强度要求的情况下，2％的用户使用前20个最常用的密码之一。含义：如果攻击者仅获得20次尝试，则您网站上50个帐户中的1个将是可破解的。
要阻止这种情况，需要计算密码的熵，然后应用阈值。美国国家标准技术研究院（NIST）特殊出版物800-63有一组非常好的建议。当与字典和键盘布局分析结合使用时（例如，“ qwertyuiop”是错误的密码），可以以18位的熵级别拒绝所有错误选择的密码的99％。简单地计算密码强度并向用户显示视觉强度计是好的，但还不够。除非强制执行，否则很多用户很可能会忽略它。
为了使用户更轻松地使用高熵密码，强烈建议使用Randall Munroe的Password Strength xkcd。
利用Troy Hunt的“我已拥有” API来检查用户密码，以防在公共数据泄露中泄露密码。
第六部分：更多内容-或：防止快速射击登录尝试
首先，请看一下数字：密码恢复速度-您的密码可以使用多长时间
如果您没有时间浏览该链接中的表，请参见以下列表：
它需要几乎没有时间来破解弱密码，即使你用算盘咔吧
如果不区分大小写，则几乎不需要时间来破解字母数字的9个字符的密码
如果密码的长度少于8个字符，几乎不需要花费任何时间就可以破解复杂的，符号，字母和数字以及大小写的密码（台式PC可以在一个问题中最多搜索7个字符的整个密钥空间）天或什至数小时）
但是，如果您每秒只能尝试一次，则破解6个字符的密码将花费大量时间！
那么我们可以从这些数字中学到什么呢？好了，但有很多，但是我们可以专注于最重要的部分：防止大量快速连续射击尝试（即强力攻击）确实并不那么困难。但是，正确地阻止它似乎并不容易。
一般来说，您有三种选择都可以有效地抵抗暴力攻击（和字典攻击），但是由于您已经在使用强密码策略，因此这不应该成为问题：
在N次失败尝试后提出验证码（令人讨厌并且经常无效-但我在这里重复我自己）
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最佳实践建议（必读列表中的链接1），即使被认为是限制性的，也应被视为最佳实践。
根据经验，我会说：密码策略越强，对用户进行延迟的麻烦就越少。如果您需要强壮的（区分大小写的字母数字+所需的数字和符号）9个以上的字符密码，则可以在激活限制之前为用户提供2-4次无延迟的密码尝试。
DoS攻击这种最终的登录限制方案将是非常不切实际的。最后，始终允许持久（cookie）登录（和/或经过CAPTCHA验证的登录表单）通过，因此在攻击进行期间，合法用户甚至都不会受到延迟。这样，非常不切实际的DoS攻击就变成了极为不切实际的攻击。
此外，对管理员帐户进行更积极的限制是有意义的，因为这些是最有吸引力的切入点
第七部分：分布式蛮力攻击
顺便说一句，更高级的攻击者将尝试通过“传播其活动”来规避登录限制：
在这里，最佳做法是记录系统范围内失败登录的次数，并使用站点错误登录频率的运行平均值作为基础，然后对所有用户强加上限。
太抽象了？让我改一下：
假设您的网站在过去3个月中平均每天有120次错误登录。使用该值（运行平均值），您的系统可能会将全局限制设置为该值的3倍，即 24小时内360次失败尝试。然后，如果所有帐户的失败尝试总数在一天之内超过该次数（甚至更好，监视加速速率并以计算出的阈值触发），它将激活系统范围的登录限制-这意味着所有用户的延迟很短（不过，除了Cookie登录名和/或备用CAPTCHA登录名之外）。
我还发布了一个具有更多细节的问题，并就如何避免防御分布式蛮力攻击进行了很好的讨论。
第八部分：两方面身份验证和身份验证提供程序
凭据可能会受到威胁，无论是利用漏洞，写下或丢失密码，笔记本电脑的钥匙被盗，还是用户在钓鱼网站中输入登录名。可以使用两因素身份验证进一步保护登录，该因素使用带外因素，例如从电话，SMS消息，应用程序或软件狗接收到的一次性代码。几个提供程序提供两因素身份验证服务。
身份验证可以完全委派给单点登录服务，其他提供商在该处处理收集凭据。这将问题推送到受信任的第三方。Google和Twitter均提供基于标准的SSO服务，而Facebook提供类似的专有解决方案。
关于Web身份验证的必读链接
- OWASP身份验证指南 / OWASP身份验证备忘单
- Web上客户端身份验证的注意事项（麻省理工学院的研究论文）
- 维基百科：HTTP cookie
- 用于后备身份验证的个人知识问题：Facebook时代的安全性问题（非常可读的伯克利研究论文）