身份认证设计的基本准则

标签: 身份认证 设计 | 发表时间:2013-01-08 13:32 | 作者:
出处:http://www.iteye.com

身份认证设计的基本准则

密码长度和复杂性策略

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

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



 

王文君  李建蒙 编著

电子工业出版社出版

 

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [身份认证 设计] 推荐:

身份认证设计的基本准则

- - ITeye博客
密码认证作为当前最流行的身份验证方式,在安全方面最值得考虑的因素就是密码的长度. 一个强度高的密码使得人工猜测或者暴力破解密码的难度增加. 下面定义了高强度密码的一些特性. 对于重要的应用,密码长度最少为6;对于关键的应用,密码长度最少为8;对于那些最关键的应用,应该考虑多因子认证系统. 有的时候仅有长度约束是不够的,比如说12345678、11111111这样的密码,长度的确是8位,但极容易被猜测和字典攻击,所以这时候就需要增加密码复杂度.

基于token的多平台身份认证架构设计 - 一点一滴的Beer - 博客园

- -
在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情. 随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了  一个服务器,N个客户端的格局 . 不同的客户端产生了不同的用户使用场景,这些场景:. 综上所述,它们的身份认证方式也存在一定的区别. 本文将使用一定的篇幅对这些场景进行一些分析和梳理工作.

网络数字身份认证术

- - 酷 壳 – CoolShell
这篇文章是《 HTTP API 认证授权术》的姊妹篇,在那篇文章中,主要介绍了 HTTP API 认证和授权技术中用到的 HTTP Basic, Digest Access, HMAC, OAuth, JWT 等各种方式,主要是 API 上用到的一些技术,这篇文章主要想说的是另一个话题——身份认证.

教育信息化、信息孤岛与身份认证

- - writing for time
最近接触的项目和需求中,统一身份认证的问题反复出现,花了不少功夫去了解身份认证这块相关的标准和协议. 身份认证/授权这部分涉及的概念真是五花八门,一度把我搞得七荤八素,相关概念包括但不限于:session,cookie,OpenID,OAuth2,CAS,JWT,SSO,Token,SAML,Shibboleth(以上这些概念并不都在同一层面).

为什么 Istio 要使用 SPIRE 做身份认证?

- - Jimmy Song - 宋净超的个人博客 – 博客
今年 6 月初, Istio 1.14 发布 ,该版本中最值得关注的特性是新增对 SPIRE 的支持. SPIFFE 和 SPIRE 都是 CNCF 孵化项目,其中 SPIRE 是 SPIFFE 的实现之一. 本文将带你了解 SPIRE 对于零信任架构的意义,以及 Istio 是为何使用 SPIRE 实现身份认证.

浅析基于Spring Security 的身份认证流程

- - 掘金 后端
在企业级项目中,目前较为流行的的认证和授权框架主要是 Spring Security 和 Shiro. Spring Security 相对于 Shiro 具有更加丰富的功能和社区资源,但相对而言 Spring Security 的上手难度也要大于 Shiro. 因此,一般中大型项目会更倾向于使用 Spring Security 框架,而小型项目多采用 Shiro 框架.

聚焦安全:互联网场景的身份认证方法分析

- - 技术改变世界 创新驱动中国 - 《程序员》官网
2011年末多家国内网站用户信息泄露,让许多人意识到安全不再是与自己无关的话题. 2012年3月《程序员》封面报道,我们分别从身份认证、数据库安全、中间平台、终端用户、云计算等几个角度为大家剖析安全所涉的方方面面. 身份认证是一个古老的话题,从最早的户籍造册,到今天的2代身份证或社会保险号码,“我是谁”或“他是谁”的问题贯穿着人类社会的发展.

全方面解析微服务架构下的统一身份认证和授权 - 知乎

- -
本文讨论基于微服务架构下的身份认证和用户授权的技术方案,在阅读之前,最好先熟悉并理解以下几个知识点:. 微服务架构相关概念:服务注册、服务发现、API 网关. 身份认证和用户授权:SSO、CAS、OAuth2、JWT. 文章在涉及到上述知识内容时,会附上参考链接. 当企业的应用系统逐渐增多后,每个系统单独管理各自的用户数据容易行成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进.

下一代自动贩卖机如何支持烟酒药品销售?结合区块链与数字身份认证技术

- - 商业不靠谱
限于身分认证技术,市面上的贩卖机不能贩售烟酒,区块链新创BiiLabs与业安科技创下全球首例,结合区块链与数字身份认证技术,让传统贩卖机一秒升级. 「智能贩卖机」是今年商超共同的关键字,少了人工盘点存货,清点营收、销售的数据自动勾稽到邻近的超商门市,是替超商经营加值的秘密武器,校园、办公大楼、百货公司,都能见到贩卖机踪影.

为了设计而设计

- - 幻风阁|kent.zhu'sBlog
我有个习惯,每天晚上睡前会搜罗一遍最新的App用用. 最开始的时候ios的App还相对比较朴实,强调功能的实用性,后来不知何故吹起一阵ios的App必须足够精美的怪风. 于是乎,各类App纷纷上演换装游戏,一个比一个做的精美,即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……. 上周末跟Tony和Angela在下厨房喝茶闲聊,我说目前的移动产品设计可以分为2类,一类是做给用户用的,一类是做给设计师们欣赏与收藏的.