密码存储的历程

1. 密码存在纯文本里，通过sql注入可以获得用户名和密码
2. 单向哈希函数，系统只存哈希函数。出现漏洞时，只有哈希函数会暴露。黑客通过彩虹表，计算一次密码就将其放入表中，多猜几次就破解了密码
3. 为每个用户的密码生成随机字节（称为盐），然后（盐+密码）一起作为单向哈希函数的输入，然后计算出独特的哈希，这样可降低彩虹表的有效性。但是因为硬件的计算能力太快了现在，所以还是多猜几次就能破解密码
4. 使用自适应单向函数来验证密码，这些单向函数会有意占用大量系统资源（例如CPU、内存等），这样可以增加恶意用户攻击系统的难度，常见的有bcrypt、PBKDF2、scrypt和argon2。由于自适应单向功能故意耗费资源，因此为每个请求验证用户名和密码将显著降低应用程序的性能。Spring Security（或任何其他库）无法加快密码的验证，因为安全性是通过使验证资源密集而获得的。鼓励用户将长期凭据（即用户名和密码）交换为短期凭据（即会话、OAuth令牌等）。短期凭证可以快速验证，而不会造成任何安全损失。

对于漏洞的保护

CSRF（跨站点请求伪造）

解释

首先我们登陆了银行的网站，这个时候就会有一个cookie，如果这个时候我们访问了一个赌博网站。赌博网站有一个提交按钮，他的路径和银行转账的路径是一样的，但是转账的目标是赌博网站，这样就无意中向恶意用户转了100元。发生这种情况的原因：尽管赌博网站看不到cookie，但是请求一样，就会把刚才那个cookie带着和请求一起发送，这样就可以直接发起转账了。

防止CSRF攻击

产生的原因以及措施

是因为来自受害者网站的HTTP请求和来自攻击者网站的请求完全相同。为了防止CSRF攻击，我们需要确保请求中存在邪恶网站无法提供的东西，以便我们可以区分这两个请求。

措施一 同步器令牌模式（Synchronizer Token Pattern,主要的和最全面的）

幂等性和安全性的解释——》https://www.freesion.com/article/75351378603/
核心思路：确保每个HTTP请求除了我们的会话cookie外，还需要HTTP请求中必须存在一个名为CSRF令牌的安全随机生成值。提交HTTP请求时，服务器必须查找预期的CSRF令牌，并将其与HTTP请求中的实际CSRF令牌进行比较。如果值不匹配，HTTP请求应该被拒绝。

关键：将实际的实际的CSRF令牌放在HTTP参数或HTTP头中，要求cookie中的实际CSRF令牌不起作用，因为发请求时回带上cookie，如果cookie里的令牌还有作用，那就相当于什么都没做。

措施二 SameSite属性(Spring Security不直接控制会话cookie的创建，因此它不支持SameSite属性)

服务器在设置cookie时，设置SameSite属性，这样其他网站发请求时就不会带上cookie。