多年来，存储密码的标准机制已经发展。在开始时，密码以纯文本格式存储。假设密码是安全的，因为数据存储密码保存在所需的凭据中以访问它。但是，恶意用户能够找到使用SQL注入等攻击获取用户名和密码的大量“数据转储”的方法。随着越来越多的用户凭证成为公共安全专家意识到我们需要做更多的工作来保护用户密码。 然后鼓励开发人员在通过单向散列（如SHA-256）运行密码后存储密码。当用户尝试进行身份验证时，散列密码将与他们键入的密码的哈希值进行比较。这意味着系统只需要存储密码的单向散列。如果发生了破坏，则只暴露密码的单向哈希。由于哈希是一种方式，并且在计算上难以猜测给定哈希的密码，因此在系统中找出每个密码是不值得的。为了打败这个新系统，恶意用户决定创建名为Rainbow Tables的查找表。他们不是每次都在猜测每个密码，而是计算密码一次并将其存储在查找表中。 为了降低Rainbow Tables的有效性，鼓励开发人员使用salted密码。不是仅使用密码作为哈希函数的输入，而是为每个用户的密码生成随机字节（称为盐）。 salt和用户的密码将通过哈希函数运行，该哈希函数产生唯一的哈希值。盐将以明文形式存储在用户密码旁边。然后，当用户尝试进行身份验证时，散列密码将与存储的salt的哈希值和他们键入的密码进行比较。独特的盐意味着Rainbow Tables不再有效，因为每个盐和密码组合的哈希值都不同。 在现代，我们意识到加密哈希（如SHA-256）不再安全。原因是，使用现代硬件，我们可以每秒执行数十亿次哈希计算。这意味着我们可以轻松地单独破解每个密码。 现在鼓励开发人员利用自适应单向函数来存储密码。使用自适应单向函数验证密码是故意的资源（即CPU，内存等）密集型。自适应单向函数允许配置“工作因子”，随着硬件变得越来越好。建议将“工作因素”调整为大约1秒钟以验证系统上的密码。这种折衷是为了让攻击者难以破解密码，但不是那么昂贵，这给你自己的系统带来了过多的负担。 Spring Security试图为“工作因素”提供一个良好的起点，但鼓励用户为自己的系统定制“工作因素”，因为不同系统的性能会有很大差异。应该使用的自适应单向函数的示例包括bcrypt，PBKDF2，scrypt和Argon2。 由于自适应单向函数是有意为资源密集型的，因此为每个请求验证用户名和密码会显着降低应用程序的性能。 Spring Security（或任何其他库）无法加速密码验证，因为通过使验证资源密集，可以获得安全性。鼓励用户交换短期凭证（即会话，OAuth令牌等）的长期凭证（即用户名和密码）。短期凭证可以快速验证，而不会有任何安全损失。