后端开发--身份和访问管理【密码篇】_如何控制项目中的用户密码访问-优快云博客

纯文本密码问题（plain text）

Plain Text Password Hypocratic Oath纯文本密码誓约
As a developer, it is my responsibility to take security seriously and not implement weak systems including storing plain text passwords.
作为一个开发者，我有责任认真对待安全问题，不实施包括存储纯文本密码在内的薄弱系统。

加密方式

使用同一个密钥key ：在一侧加密信息并从另一侧解密信息。在数据库中存储的也是加密过后的密码，这样，入侵者必须同时拿到我们的数据表和密钥才能解密密码。

这种密钥的设计常见的算法有：3DES、Blowfish、AWS

非对称加密（RESHOOT）：使用两个密钥，一个是私有的，一个是公共的。私有的用来加密，共有的key用来解密。这种非对称加密方式常见于 HTTPS、TLS/SSL等协议。【http与https的区别：菜鸟教程：http vs https】

这种密钥的设计常见的算法有：RSA、Elliptic、Curve

哈希 Hash： 这是一种单向加密方式，我们无法从加密后的文本回溯到原始的密码。

原理： 数据库中储存的也是哈希加密过的版本，API server服务器通过对比前端输入的密码的哈希值和数据库中储存的哈希值是否相等来判断密码是否正确。当我们的数据表被非法获取的时候，只能拿到加密过的哈希值，再次输入时，API server会对其再进行一次加密，从而无法匹配。
这种密钥的设计常见的算法有：bcrypt、scrypt 、SHA-1、MD5，最好使用前两种算法，后两种散列函数过于简单，不应该用于散列密码。原因见下一条。
hash的破解： 如果用户输入的密码是常见的，那么可以对大量常见的密码进行hash加密生成哈希值，对比数据库中的哈希值，从而破解。这种破解方式被称为RainbowTables，需要大量的计算。而如果哈希算法的计算量比较大的时候，就很难对大量的常见密码计算其哈希值，因而建议选择 bcrypt、scrypt 这两种计算量比较大的哈希算法，SHA-1、MD5两种哈希算法计算量小，易于破解。
改进： 盐散列。即使是一样的密码，通过对密码前面加随机的“盐” ，和密码组合进行哈希计算，从而得到不同的哈希值，增加复杂度，使生成哈希表的时间复杂度更高。数据库中需要存储盐和哈希值。
salt 需要满足：
- 足够长
- 真正随
Salt Rounds 盐轮 ：这是密码和盐应该重新散列多少次的成本因素。换句话说，如果您选择 10 个盐轮，则计算将执行 2^10 = 1024 次。每次尝试都将上一轮的哈希值作为输入。执行的轮次越多，计算哈希所需的计算量就越多。这不会导致单次尝试花费大量时间（即在登录时检查密码），但会在尝试暴力破解或生成彩虹表时增加大量时间，从而增加破解难度。