介绍媒体几乎每天都会报道一些窃取密码的新闻。媒体报道的密码窃取大多数是密码存储方案泄露、存储方案存在漏洞。通常会有大量的凭据遭到破坏,从而影响大量的WEB站点或者其他应用程序。本文提供了一个正确存储密码、密码问题及答案和类似凭据信息的指导。合适的存储方案能防止证书被盗、被泄露和恶意使用。信息系统通过各种保护形式来存储密码和其他凭据。常见的漏洞让窃密者能通过SQL注入等攻击向量来窃取被保护的密码。受保护的密码也有可能被攻击者通过其他形式(如日志、转储和备份文件等)窃取。 这份指导会教你如何防止凭据被盗,但是大部分内容是关于防止密钥泄露的。这个指导同样能帮助你设计抵御用户凭据被盗或防止窃密者访问凭据信息的系统。你可以参阅httphttp://goo.gl/Spvzs以获取更多信息。 指导不限制字符集和设置最大凭据长度一些系统会做如下限制:1)特定的字符类型。2)系统能够接受的凭据长度(因为这有助于防止SQL注入、跨站脚本、命令执行和其他形式的注入攻击)。这些善意的限制让系统更易于受到暴力破解这类的攻击。 不要在登陆入口或存储凭据时使用过短、没有长度限制的、只限制字符集或编码的密码。除此之外,还要使用编码、转码、隐藏、忽略和其他最佳实践来消除注入攻击的风险。 合理的长密码的长度是160,太长的密码可能会让系统出现DDOS攻击漏洞[1]. 使用一个强大的加密凭据专用的盐(salt)盐是固定长度的、用于加强密码学可靠性的随机值。将凭据数据加入盐中并将其作为保护函数的输入。形式如下:
遵循如下的实践来实现凭据专用的盐的生成:
加盐是为了达到两个目的:1)防止两个相同凭据的生成同样的加密数据;2)增加熵值让保护功能不再依赖凭据的复杂度。第二个还能让个人凭据免遭彩虹表攻击。 利用攻击者不可行验证用来保护存储凭据的函数应该平衡攻击者和防卫验证。防御者需要一个即使在访问高峰时也能接受的验证用户凭据的响应时间。但是要知道,生成“凭据<=>保护数据”的映射表的时间与攻击者的硬件(GPU、FPGA)和技术(基于字典、暴力破解等)能力有关。 下面两种方法都不完美。 使用可以自适应的单向函数自适应的单向函数进行单向的不可逆转换。每个函数都可以配置“工作因子”。如何实现不可逆性、支配工作因子(如时间、空间和并行度)将不在这里讨论。 选择:
protect()的伪代码如下:
设计师选择单向自适应函数来实现protect()函数,因为这些函数相对于哈希函数,能够通过修改配置改变它的执行耗时(线性或指数方式)。防卫者调整工作因子来与攻击者持续增长的硬件能力赛跑。这些自适应的单向函数的实现必须工作因子调整,从而在阻碍攻击者的同事提供可接受的用户体验。 此外,自适应的单向函数不能有效的阻止常见的基于字典的凭据破解,用户规模和加盐对于此丝毫没有帮助。 工作因子一般而言,资源是有限的,一个常见的调整工作因子(或耗时)的法则是:让protect()函数在不影响用户的体验和增加额外的超预算硬件的前提下,尽可能的降低速度。因此,在注册和身份验证时,你可以改变protect()的参数,让这个计算在你的硬件上耗时1秒钟。这样一来,它就不会因为过慢影响到你的用户,同时又能有效阻止攻击者的尝试轻轻。 虽然有推荐的最小迭代次数来确保数据的安全,但是由于技术在发展,这个值至少每年需要改变一次。一个知名的迭代次数的例子是苹果公司,他们加密iTunes密码(使用PBKDF2)的迭代次数是10000。但是你要知道,使用单一的工作因子并不适合所有的情况。实验很重要[*6] 杠杆键函数键函数,如HMACs算法,使用私钥和输入参数计算单向(不可逆)转换。对于HMACs,它继承了哈希函数的属性,包括:速度、允许即时验证。密钥的长度影响不可行长度和/或空间要求——甚至是常见的凭据。设计者使用键函数来保护存储的凭据:
protect()伪代码如下:
盐方案的持续改进依赖于正确的密钥管理。 设计能处理密码被泄露的密码存储的方法实际上,受保护凭据频繁被盗的现状逼迫着我们做“失败设计”。如果发现凭据被盗,一个好的凭据存储方案能轻松的对被盗凭据执行安全操作并使用备选的凭据验证流程:
引用
作者和主编John Steven - john.steven[at]owasp.org (author) Jim Manico - jim[at]owasp.org (editor) 原文属性最后修改时间:This page was last modified on 25 March 2014, at 09:53. |
英文原文: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet