身份认证设计的基本准则

 

身份认证设计的基本准则

密码长度和复杂性策略

密码认证作为当前最流行的身份验证方式，在安全方面最值得考虑的因素就是密码的长度。一个强度高的密码使得人工猜测或者暴力破解密码的难度增加。下面定义了高强度密码的一些特性。

（1 ）密码长度

对于重要的应用，密码长度最少为6 ；对于关键的应用，密码长度最少为8 ；对于那些最关键的应用，应该考虑多因子认证系统。

（2 ）密码的复杂度

有的时候仅有长度约束是不够的，比如说12345678 、11111111 这样的密码，长度的确是8 位，但极容易被猜测和字典攻击，所以这时候就需要增加密码复杂度。下面列举了一些提供复杂度的策略。

— 至少一个大写字母（ A ～ Z ）。

— 至少一个小写字母（ a ～ z ）。

— 至少一个数字（ 0 ～ 9 ）。

— 至少一个特殊字符（ !@#$%^& 等）。

— 定义最少密码长度（如 8 个字符）。

— 定义最长密码长度（如 16 个字符）。

— 不能出现连续的字符（如 123 、 abc 、 def ）。

— 不能出现连续相同的字符（如 1111 ）。

一旦我们定义好了这些策略，在用户注册时就可以强制用户输入高强度的密码，从而提高密码的安全性。

实现一个安全的密码恢复策略

上一节介绍了密码的长度和复杂度，有时，太复杂的密码自己都给忘记了，该怎么办？所以一般来说，一个应用会提供密码恢复功能。鉴于大部分应用都提供了电子邮箱这具有唯一性字段的恢复方式，所以可见最常见的方式就是让用户输入电子邮箱，输入电子邮箱后，一般会有以下两种解决方法。

（1 ）把原来的密码发送到用户信箱中去。

我个人的意见是，如果这样做，说明这个应用可以得知你的密码明文，这与系统只存hash/ 加密值的单项策略相违背，若哪一天这个程序的数据库被攻克，所有的明文就会被很容易地得知，所以这种方式还是不值得提倡。

（2 ）重设一个临时密码，用户用这个密码登录然后修改密码。

这是一个相对较好的方法，通常为了增加安全性，我们还可以给这个临时密码一个有效期，如用户必须24 小时内使用这个密码登录等。

上面的密码恢复策略是基于一个事实的，就是你的电子邮箱应该足够安全（没有人知道你的邮箱密码）。但是如果这个应用具有CSRF 漏洞，即电子邮件可能被修改成一个攻击者的邮箱而受害者却毫无所知，这时候如果进行密码恢复就会把密码发到攻击者的信箱里，那么该怎么办呢？

答案是更新重要字段时需要重新认证。比如用户的密码、电子邮件等，如果用户需要更新，则弹出一个对话框让用户输入原先的密码，这样就可以有效地防止CSRF 攻击。

重要的操作应通过HTTPS传输

对于重要的操作，如登录、修改密码等，一定要通过HTTPS 进行传输。我们就以Tomcat 为例，说明一下如何进行配置，使得指定的URL 必须走HTTPS 。

首先是产生一个证书。为了说明方便，我们采用Java 提供的keytool 产生一个自认证证书，命令如下：%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA 。然后回答一些问题，这里注意设置证书库的密码和key 的密码，我们这里设置为changeit ，这样就会产生一个证书库，如图10-22 所示。

图10-22  用Java 生成一个证书库

然后在把产生的 .keystore 复制到 {TOMCAT_HOME}\conf 目录下，配置 server.xml 如下：

<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"

           port="8443" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="${user.home}/.keystore" keystorePass="changeit" />

—   最后我们再配置APP 应用下的WEB-INF\web.xml 如下：

<security-constraint>

    <web-resource-collection>

        <web-resource-name>must https</web-resource-name>

        <url-pattern>/login.jsp</url-pattern> ➊

    </web-resource-collection>

    <user-data-constraint>

        <transport-guarantee>CONFIDENTIAL</transport-guarantee>

    </user-data-constraint>

</security-constraint>

➊ 设置哪些URL 需要走HTTPS 。

认证错误信息以及账户锁定

下面是一些不正确的认证错误信息：

— 登录失败，用户 Kevin 的密码错误。

— 登录失败，无效的用户名。

— 登录失败，该用户已被禁用。

— 登录失败，该用户没有被激活。

正确的表达方式应该是唯一的一种：

— 登录失败，用户名或密码错误。

不正确的认证错误信息可能会导致字典攻击或者暴力破解，所以我们要尽可能地给出一个很普遍的错误信息。

此外为了防止暴力攻击，我们可以设定下列规则：

— 第一次登录失败，下一次登录至少间隔 5s 。

— 第二次登录失败，下一次登录至少间隔 15s 。

— 第三次登录失败，下一次登录至少间隔 45s 。

— 第四次登录失败，集成图形验证码 CAPTCHA ，让用户输入图片中的字符串。

如果有足够明显的证据显示是暴力破解（如每分钟进行了100 次尝试），IP 地址或者Session ID 应该在接下来一段时间（如15 分钟）被阻止，在这种情况下，我们应该给出清楚明白的错误信息，说明为什么这个登录会失败。

 

本文节选自《Web 应用安全威胁与防治——基于OWASP Top 10 与ESAPI 》

 

王文君  李建蒙 编著

电子工业出版社出版