web安全开发指南--认证

1、认证

1.1、       认证和密码管理安全规则

1	认证控制必须只能在服务器端执行。
2	除了指定为公开的资源，对所有其它资源的访问都必须先经过认证。
3	为所有关键凭证实施防“暴力破解”策略（参考暴力破解）。
4	当业务系统需要连接到第三方系统并存取敏感信息时，必须要求进行认证，认证的凭证不允许硬编码到代码中。
5	只使用HTTP POST请求来发送认证凭证，并且服务器只接受POST请求。
6	口令必须通过加密通道来传输。注：所有敏感数据都要满足此规则。
7	执行口令长度和复杂度检查【1.3、参见口令复杂度策略】。
8	不允许在密码输入框中显示明文密码。
9	为所有password类型的form或input标签加入AUTOCOMPLETE="off"属性，该属性用于告诉浏览器不记住当前输入的口令。
10	【可选建议】记录用户上一次成功登录的信息并在下一次登录时给予显示。
11	【可选建议】使用多因素认证，比如数字证书、短信验证码、动态口令等。
12	【可选建议】进行关键操作时要求用户重新认证（比如输入短信验证码或口令等）。
13	【可选建议】从访问站点的首页开始直到用户登录页（即输入用户名密码的页面）都使用https，避免从起始的http状态切换到https状态（最好是全站https）。

 

1.2、       修改密码功能

简要描述	当用户密码泄漏或者有时候用户自己想要去修改密码，此时需要系统提供“修改密码”的功能。
解决方案	修改新密码需要旧密码，并且需要重新确认一次新密码； 其它请参考认证和密码管理安全规则1、3、5、6、7、8和9
备注

1.3、       口令复杂度策略

简要描述	弱口令很容易被暴力破解，口令越弱，被暴力破解的成功率就越高。
解决方案	设置密码最小密码长度（建议6个字符）和最大长度（建议128个字符）； 设置密码复杂度要求（建议数字、大小字母和特殊字符4选2）； 【可选建议】对用户使用过的历史密码进行hash并存储，设置的新密码时，使用新密码的hash和历史密码的hash做对比，保证用户不能在过短时间内设置两次相同密码； 正常情况下，不允许用户修改或关闭密码复杂度验证，特殊情况下，可允许只对用户提出安全提示或允许用户进行关闭；
备注

1.4、       口令的存储策略

简要描述	密码是具有保密性的，不应当存在密码被还原成明文的情况。管理员或服务人员可以在不需要旧密码的情况下为用户重置新密码，因此，不存在需要还原明文的理由，常用的机制是使用哈希算法来存储密码，但是现今有些算法已经证明是不安全的，所以应当确保使用时选择足够安全的算法。
解决方案	1.4.1、对于不需要还原口令明文的场景（以下二选一）： 使用sha256对口令进行hash后再存储； 如果使用MD5，则应为每个用户口令添加独立的salt值（比如userid）并hash后再存储（参考附录11.9.3）； 1.4.2、对于需要还原口令明文的场景： 使用AES128或以上的强安全算法对口令进行加密后再存储（参考附录11.9.1），并安全地保护密钥（参考 加密解密à密钥的保存）； 1.4.3、如果没有特殊需求，不要将口令密文或哈希值以任何形式返回给用户。
备注		除了口令之外，对于所有被识别出来的业务敏感数据在存储时应满足解决方案中的要求。

1.5、       重置密码/找回密码/忘记密码

简要描述	为重置密码/找回密码/忘记密码等重要模块提供安全开发建议。
解决方案	当使用回答问题的方式找回密码时，应保证所提供的问题的答案是难以猜测的也是难以通过公共资源获取的，同时建议需要用户正确回答两个或两个以上的问题，比如，我最喜欢的一句话，我最想去的地方等等。 如果通过Email的方式重置密码，则应将重置密码用的临时URL发送到用户的注册的Email，并为其设置合理的有效期； 确保重置密码的临时URL是不可猜测和破解的； 如果使用手机验证码的方式重置密码，应保障手机验证码安全（参考手机验证码章节）； 其它请参考证和认证和密码管理安全规则规则1、3、5、6、7、8和9。
备注

1.6、       暴力破解

简要描述	应用程序必须要有足够的手段来抵御暴力破解和字典攻击。
解决方案	对暴力攻击行实施图形验证码或账户锁定策略，如果选择锁定策略，不可对账户进行永久锁定以避免造成拒绝服务攻击； 当认证失败时，不要告诉用户登录失败的具体原因，比如用户名不存在，密码不正确等，可只列举所有可能失败的原因； 【可选建议】在日志里记录用户每一次登录的信息，最起码要记录用户登录失败的信息； 【可选建议】尝试阻止同一个IP多次失败地去登录不同的账户； 【可选建议】如果用户已登录，进行多次关键操作失败后强制注销session（比如修改密码和校验短信验证码等等）；
备注

1.7、       自动登录功能

简要描述	该功能可以让用户返回原先访问的站点而不需要重新认证，对于在公共网络的用户来说是相当危险的。
解决方案	对于安全性要求较高的应用场景，不应当提供自动登录的功能，如果必须提供，应提示用户可能会存在的风险； 为持久性cookie设置合理的期限（建议不超过3天）。
备注

1.8、       手机验证码

简要描述	对于对安全性有一定要求的场合，手机验证码提供了更加安全的保障，用户只有输入系统发送的短信验证码方可进一步操作。
解决方案	设置适当的手机验证码长度（至少4位纯数字）； 为需要验证手机验证码的请求设置防暴力破解机制（比如 多次尝试账户锁定和验证码失效等）； 限制单个账户调用短信网关接口的频度（建议1分钟1次）。 为手机验证码设置合适的自动失效期（建议0.5-1个小时）； 手机验证码使用后应立即失效。
备注

1.9、       图形验证码

简要描述	图形验证码可以用来防御多种非人为操作的自动化攻击。
解决方案	保证在判断验证码之后再对请求做进一步处理； 使用强随机性函数产生验证码； 为验证码图片背景添加噪声； 图形验证码的形体尽量随机变化； 图形验证码在使用一次后立马失效。 未使用的图形验证码必须具有时效性。
备注