首页 新闻 论坛 群组 Blog 文档 下载 读书 Tag 网摘 搜索 开源 FAQ 第二书店 博文视点 程序员
频道: 研发 数据库 中间件 信息化 视频 .NET Java 游戏 移动 服务: 人才 外包 培训
    图书品种:235680
       
热门搜索: ASP.NET Ajax Spring Hibernate Java

1.3.2  密码时效和历史记录

小结:旧密码或重用的密码将给攻击者提供更多的机会

威胁:暴力攻击、账户劫持

如同应用程序会失效,用户密码也是如此,因为用户通常不会刻意定期地改变他们的密码。经常会看到用户使用和系统自身一样旧的密码,甚至连续使用很多年,而不进行任何改变。在因特网服务提供者(ISP)的电子邮件账户中,情况更是如此,因为ISP并没有提供简便的方法来改变用户密码。需要用户定期改变他们的密码,只有很少的Web站点遵循这一点。

但是,设置正确的时间间隔并不总是很容易。如果最大的密码时效是6个月,则危及密码的危险将增加。然而,如果走向另一个极端,需要用户每隔30天就改变密码,将发现用户会更多地写下他们的密码,并采用连续密码或基于日期的密码编写模式。过于频繁地要求用户改变他们的密码,反而可能降低系统的安全性。此外,如果用户每隔几个月才登录一次Web应用程序,并且发现每次都必须改变密码,他们可能会为此感到苦恼。

为了确定最佳的最大密码时效,询问自己如下几个问题:

n 受保护数据的敏感性如何?

n 用户通常多久才登录一次应用程序?

n 根据密码复杂度需求,需要多长时间来猜测一个密码?

如果Web应用程序是一个在线银行系统,可能要考虑最大为3~6个月的密码时效。另一方面,如果提供一个在线花店,可以让用户保持相同的密码一年或更长时间。

如果希望鼓励用户不时地改变他们的密码,但是并不想强加给用户最大的密码时效,可以考虑在固定时间间隔内通过电子邮件警告用户,告知他们的密码过于陈旧,同时带有一个快速链接,以允许他们即时改变密码。另一种思想是,让用户选择他们自己的密码时效需求。

与密码时效相关的是密码历史记录,这是用户在前面已经选择的密码的历史列表。每当一个密码到期时,密码历史记录可防止用户在相同的2个或3个密码之间交替改变。系统应该拒绝某种密码,这些密码匹配历史列表中的密码。许多系统可记住最近3个或5个密码,但一些系统则可能保持20个或更多密码的历史记录。保存密码历史记录并不需要大量重要的资源,因此保存尽可能多的密码通常非常有意义。

如果保存密码记录,则应该只存储密码的哈希,而不是密码本身,请参见“存储密码”一节中的解释。

尽管有了密码时效和历史记录列表,许多用户仍然决定重用相同的密码。通过多次重新设置密码,以填满历史记录列表,然后,将密码设置为初始、已经过期的密码,以此绕过这些安全措施。相应的对策是保持较长的历史记录列表,并且设置最短密码时效要求。最短密码时效指用户在再次改变他们的密码之前,必须保持的最短时间。

最短密码时效有时会带来不便,但它却很有效:一天甚至一个小时都足以防止用户通过刷新历史记录列表来重新设置密码。如果实施最短密码时效,则必须确保允许管理员改写该策略。

密码只不过是一个含糊的秘密单词或短语。假设有足够的时间,通过暴力攻击方法,或者通过操作系统或应用程序的弱点进行攻击,攻击者可以最终猜测出密码。当密码失效时,攻击者危害密码安全的风险就会增加。此外,如果入侵者获得了密码,但用户没有得到警告,则只要密码有效,入侵者就可以持续使用该密码。如果密码没有失效,则在用户手工改变密码之前,入侵者都可以进行访问。

密码时效和历史记录需要额外的数据库字段来跟踪何时设置密码,同时也需要额外的字段来保持当前密码的列表。哈希密码,并将其和历史记录列表中的每项进行比较,这些都需要额外的处理过程。可能希望针对各个用户或组采用不同的时效策略,或者选择一个系统范围的策略。系统范围策略的一个优点是:如果当前出现重要的安全事故(如服务器侵入),则可以立刻废除所有的密码。

用户成功通过验证进入系统,并在允许用户访问系统之前,应该立刻检查密码的截止日期。如果重点验证单独的包含库,则可以更容易地执行密码时效验证。如果密码还没有到期,但已经接近截止日期,则可能希望提前几天警告用户。图1-5是过期密码屏幕信息的示例。

当验证用户的新密码时,应该检查密码的历史记录和最短密码时效。

图1-5  过期密码屏幕示例

安全策略

n 设置适合于应用程序和用户的最长密码时效。

n 保持最近密码列表,以防止密码重用。

n 如果可能,实施密码重新设置之间的最短时间间隔。

查看所有评论(0)条】

最近评论



正在载入评论列表...
热点评论