身份认证设计的基本准则

身份认证设计的基本准则

密码长度和复杂性策略

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

(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》

身份认证设计的基本准则

王文君  李建蒙 编著

电子工业出版社出版

 

 

 

你可能感兴趣的:(设计)