10.10.1密码历史记录-Spring Security用户手册-Java-IT技术博客

10.10.1密码历史记录

多年来,用于存储密码的标准机制已经发展。最初,密码以纯文本格式存储。假定密码是安全的,因为数据存储密码已保存在访问它所需的凭据中。但是,恶意用户能够使用SQL Injection这样的攻击找到方法来获取用户名和密码的大型“数据转储”。随着越来越多的用户凭证成为公共安全专家,我们意识到我们需要做更多的工作来保护用户密码。


然后鼓励开发人员在通过诸如SHA-256之类的单向哈希运行密码后存储密码。当用户尝试进行身份验证时,会将散列的密码与他们键入的密码的散列进行比较。这意味着系统仅需要存储密码的单向哈希。如果发生违规,则仅暴露密码的一种哈希方式。由于散列是一种方式,计算出给定哈希值的密码很难计算,因此找出系统中的每个密码都不值得。为了击败这个新系统,恶意用户决定创建称为Rainbow Tables的查找表。他们不必每次都猜测每个密码,而是计算一次密码并将其存储在查找表中。


为了减轻Rainbow Tables的有效性,鼓励开发人员使用加盐的密码。不仅将密码用作哈希函数的输入,还将为每个用户的密码生成随机字节(称为salt)。盐和用户密码将通过散列函数运行,从而产生唯一的散列。盐将以明文形式与用户密码一起存储。然后,当用户尝试进行身份验证时,会将哈希密码与存储的盐的哈希值和他们键入的密码进行比较。唯一的盐意味着Rainbow Tables不再有效,因为每种盐和密码组合的哈希值都不同。


在现代,我们意识到加密哈希(例如SHA-256)不再安全。原因是使用现代硬件,我们可以每秒执行数十亿次哈希计算。这意味着我们可以轻松地分别破解每个密码。


现在鼓励开发人员利用自适应单向功能来存储密码。具有自适应单向功能的密码验证有意消耗大量资源(即CPU,内存等)。自适应单向功能允许配置“工作因数”,该因数会随着硬件的改进而增加。建议将“工作因数”调整为大约1秒钟,以验证系统上的密码。这种权衡使攻击者难以破解密码,但代价却不高,这给您自己的系统带来了沉重负担。 Spring Security试图为“工作因素”提供一个良好的起点,但是鼓励用户为自己的系统自定义“工作因素”,因为不同系统之间的性能会有很大差异。应使用的自适应单向功能示例包括bcrypt,PBKDF2,scrypt和Argon2。


由于自适应单向功能有意占用大量资源,因此为每个请求验证用户名和密码都会大大降低应用程序的性能。 Spring Security(或任何其他库)无法采取任何措施来加快密码的验证速度,因为通过增加验证资源的强度来获得安全性。鼓励用户将长期凭证(即用户名和密码)交换为短期凭证(即会话,OAuth令牌等)。可以快速验证短期凭证,而不会损失任何安全性。


标签: Spring SecuritySpring文档Spring Security中文教程SpringSecurity手册