验证机制

保障验证机制的安全

使用可靠的证书

应强制执行适当的最小密码要求。这些要求包括：最小密码长度，使用字母、数字和排版字符，同时使用大、小写字符，避免使用字典中的单词、名称和其他常见密码。避免以用户名为密码，避免使用和以前的密码相似或完全相同的密码
应使用唯一的用户名
系统生成的任何用户名和密码应具有足够的随机性，其中不包含任何顺序，及时攻击者访问大量练习生成的实例也无法对其预测。
允许用户设置足够强大的密码。

安全处理证书

应以不会造成非授权泄露的方式创建、保存和传送所有证书
应使用公认的加密技术（SSL）保护客户端与服务器间的所有通信。既无必要也不需要使用定制解决方案保护传输中的数据。
如果认为最好在应用程序的不需验证的区域使用HTTP，必须保证使用HTTPS加载登录表单，而不是在提交登录信息时才转换到HTTPS。
只能使用POST请求向服务器传输证书。绝不能讲证书放在URL参数或cookie中。决不能将整数返还给客户端，即使通过重定向参数也不行。
所有服务器-客户端应用程序组件应这样保存证书：即使攻击者能够访问应用程序数据库中存储的所有相关数据，它们也无法轻易恢复证书的原始值。达到这种目的的最常用的方法是使用强大的散列函数，并对其进行“加salt处理”以降低预先计算的离线攻击的危害。该sale应特定于拥有密码的账户，以防止攻击者重播或替换散列值。
一般来说，客户端“记住我”功能应仅记忆如用户名之类的非保密数据。在安全要求较低的应用程序中，可适当允许用户选择一种工具来记住密码。在这种情况下，客户端不应保存明文证书。
应使用一种密码修改工具，要求用户定期修改其密码
如果以非正常交互的形式向新建账户分配证书，应以尽可能安全的形式传送证书，并设置时间限制，要求用户在第一次登陆时修改证书，并告诉用户在初次使用后销毁通信通道。

正确确认证书

应确认完整密码。也就是说，区分大小写，不过滤或修改任何字符，也不截断密码。
应用程序应在登陆处理过程中主动防御无法预料的事件。例如，根据所使用的开发语言，应用程序应对所有API调用使用“全捕获”型异常处理程序。这些程序应明确删除用于控制登录状态的所有会话和方法内部数据，并使当前会话完全失效。因此，及时攻击者以某种方式避开验证，也会被服务器强制退出。
应对验证逻辑的伪代码和实际的应用程序源代码进行仔细的代码审查，以确定故障开放条件之类的逻辑错误。
如果应用程序执行支持用户伪装功能，应严格控制这种功能，以防止攻击者滥用它获得未授权访问。鉴于这种功能的危险程序，通常有必要从面向公众的应用程序中彻底删除该功能，只对内部管理用户开放该功能，而且他们使用伪装也应接受严格控制与审核。
应对多阶段登录进行严格控制，以防止攻击者破幻登录阶段之间的转换和关系。
- 有关登录极端进展和前面验证任务结果的所有数据应保存在服务器端会话对象中，绝不可传送给客户端或由其读取
- 禁止用户多次提交一项登录信息；禁止用户修改已经被收集或确认的数据。如果需要在几个阶段使用同一个数据，应在第一次收集时将该数据保存在会话变量中，随后从此处引用该数据。
- 在每一个登录阶段，应首先合适前面的阶段均已顺利完成。如果发现前面的阶段没有完成，应立即将验证尝试标记为恶意尝试
- 为防止泄露的是哪个登录阶段失败的信息，即使用户无法正确完成前面的阶段，即使最初的用户名无效，应用程序也应总是处理完所有的登录阶段。在处理完所有的登录阶段后，应用程序应在最后阶段结束时呈现一条常规“登录失败”消息，并且不提供失败位置的任何信息
如果在登录过程中需要回答一个随机变化的问题，请确保攻击者无法选择回答问题、
- 总是采用一个多阶段登录哦过程，在第一阶段确认用户身份，并在后面的阶段向用户提出随机变化的问题。
- 如果已向某一用户提出一个特定的问题，将该问题保存在永久性用户资料中，确保每次该用户尝试登录时，向其提出相同的问题，知道该用户正确回答这个问题。
如果向某个用户提出一个随机变化的质询，将提出的问题保存在服务器端会话变量而非HTML表单的隐藏字段中，并根据保存的问题核实用户随后提供的答案。

防止信息泄露

应用程序使用各种验证机制不应通过公开的或者通过从应用程序的其他行为进行推断，来解释关于验证参数的任何信息。攻击者应无法判断是提交的哪个参数造成了问题。
应由单独一个代码组件使用一条常规消息负责响应所有失败的登录尝试。这样做可避免由不同代码路径返回的本应不包含大量信息的消息，因为消息排版方面的差异，不同的HTTP状态码、其他隐藏在HTML中的信息等内容而让攻击者看出差别，从而产生一个细微的漏洞。
如果应用程序实行某种账户锁定以防止蛮力攻击，应小心处理以防造成信息泄露。
如果应用程序支持自我注册，那么他能够以两种方式防止这种功能被用于美剧现有用户名。
- 不允许自我选择用户名，应用程序可谓每个新用户建立一个唯一的用户名，防止应用程序披露表名一个选定的用户名已经存在的信息。
- 应用程序可以使用电子邮件作为用户名。

防止蛮力攻击

必须对验证功能执行的各种质询采取保护措施，防止攻击者企图使用自动工具响应这些质询。这包括登录机制、修改密码功能和恢复遗忘密码等功能中的质询。
使用无法预测的用户名，同时阻止用户名美枚举，给完全盲目的蛮力攻击设置巨大障碍，并要求攻击者在实施攻击前已经通过某种方式发现一个或几个特殊的用户名。
一些对安全性要求极高的应用程序在检测到少数几次登录失败后应立刻禁用该账户，并要求账户所有者采取各种非常规步骤重新激活该账户。
如果采用临时攻讦账户的策略，应采取措施确保这种策略的效率。
- 为防止信息泄露导致用户名枚举，应用程序决不能投罗任何账户冻结信息。相反，应用程序应对一些列即使是使用无效用户名发起的失败登录做出响应，通过一条常规消息提出警告：如果出现多次登录失败，账户将被冻结，建议用户稍后再试。
- 应用程序不应向用户透露账户锁定标准。
- 如果一个账户被冻结，那么应用程序不用检查用户证书，直接就可以拒绝该账户的登录尝试。
- 账户锁定之类的常规应对措施对防御一种极其有效的蛮力攻击并没有帮助，即遍历大量枚举出的用户名，检查单独一个脆弱密码，如password。例如，如果5次登录失败就会触发账户冻结，这意味着攻击者能够对每个账户尝试使用4个不同的密码，而不会引起任何中断。如果一个应用程序使用许多脆弱密码，使用上述攻击手段的攻击者就能攻破许多账户。

防止滥用密码修改功能

应用程序应始终执行密码修改功能，允许定时使用的密码到期终止，并允许用户修改密码。
- 只能从已通过验证的会话中访问该功能
- 不应以任何方式直接提供用户名，也不能通过隐藏表单字段或cookie提供用户名。用户企图修改他人密码的行为属非法行为。
- 作为一项高级防御措施，应用程序应对密码修改功能加以保护，防止攻击者通过其他安全缺陷获得未授权的访问。为达到这种目的，应要求用户重新输入现有密码。
- 为防止错误，新密码应输入两次。应用程序应首先比较“新密码”与“确认新密码”字段，看他们是否匹配，如果不相匹配，返回一条详细的错误信息。
- 该功能应组织可能针对主要登录机制的各种攻击：应使用一条常规错误消息告知用户现有证书中出现的任何错误；如果修改密码的尝试出现少数几次失败，应临时冻结该动能。
- 应使用非常规方式（如电子邮件）通知用户其密码已被修改，但通知消息中不得包括用户的旧证书或者新证书

防止滥用账户恢复功能

当用户遗忘密码时，许多安全性至关重要的应用程序，通过非常规方式完成账户恢复：用户必须给呼叫中心打电话并回答一系列安全问题；新证书或重新激活代码也以非常规方式送往用户注册的家庭住址。绝大多数应用程序并不需要这种程度的安全保护，只需使用自动恢复功能即可。
精心设计的密码恢复机制需要放置账户被未授权方攻破，避免给和发扬用户造成任何使用中断。
绝对不要使用密码“暗示”之类的特性，因为攻击者可利用明显的暗示向账户发动攻击。
通过电子邮件给用户发送一个唯一的、具有时间限制的、无法猜测的一次性恢复URL是帮助用户重新控制账户的最佳自动化解决方案。
为进一步防止未授权访问，应用程序可能会向用户提出一个次要质询，用户必须在使用密码重设功能前完成该质询。

日志、监控与通知

应用程序应在日志中记录所有与验证有关的事件，包括登录、退出、密码修改、密码重置、账户冻结与账户恢复。应当在适当的地方记录所有失败与成功的登录尝试。日志中应该包含一切相关细节，但不得泄露任何安全机密。应用程序应为日志提供强有力的保护以防止未授权的方位，因为它们是信息泄露的主要源头。
应用程序的实时劲爆与入侵防御功能应对验证过程中的异常事件进行处理。
应以非常规方式向用户通报任何重大的安全事件
应以非常规方式向用户通报经常发生的安全事件。