身份认证设计的基本准则
2013-01-08 13:02
183 查看
身份认证设计的基本准则
密码长度和复杂性策略
密码认证作为当前最流行的身份验证方式,在安全方面最值得考虑的因素就是密码的长度。一个强度高的密码使得人工猜测或者暴力破解密码的难度增加。下面定义了高强度密码的一些特性。(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产生一个自认证证书,命令如下:%J***A_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》
王文君
李建蒙编著
电子工业出版社出版
相关文章推荐
- 身份认证设计的基本准则
- 身份认证设计的基本准则
- 基于token的多平台身份认证架构设计
- Soap身份基本认证方法
- ASP.Net 身份验证方法 基本的Forms认证步骤 [转]
- 基于token的多平台身份认证架构设计
- 基于任意加密货币的用户身份认证设计思路
- ASP.Net 身份验证方法 基本的Forms认证步骤
- 产品设计的一些基本准则和原理
- 印制板的基本设计准则
- 基于bitshares的身份认证系统设计思路
- Apache的应用四-- 基本身份认证
- 校园数字化建设--注册中心投标文件研究(15)--统一身份认证系统设计方案
- OA系统身份认证的设计
- php创建基本身份认证站点的方法详解
- 第二章----1,身份认证的基本流程,附上源码
- 基于LDAP的Web身份认证机制的研究与设计
- 基于token的多平台身份认证架构设计
- restful架构风格设计准则(五)用户认证和session管理
- 统一身份认证子系统详细设计与部分实现