身份认证设计的基本准则
密码长度和复杂性策略
密码认证作为当前最流行的身份验证方式，在安全方面最值得考虑的因素就是密码的长度。一个强度高的密码使得人工猜测或者暴力破解密码的难度增加。下面定义了高强度密码的一些特性。
（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
