怎么用Redis查密码又安全点，别直接暴露用户信息那种

绝对不要用明文存储用户的密码。 这是所有安全设计的底线，一旦你这么做了，无论后面用多少层安全措施，只要Redis服务器被攻破，所有用户的密码就相当于直接送给了攻击者，这个理念来源于安全领域的基本共识，即系统管理员也不应该知道用户的密码。

正确的做法是使用哈希算法，哈希算法是一种单向的加密函数，你可以把用户的原始密码“加工”成一个长度固定的、看起来像乱码的字符串（称为哈希值），这个过程的關鍵在于“单向性”：从密码计算出哈希值很容易，但想从哈希值反推出原始密码，在现有计算能力下是几乎不可能的，这样，即使黑客拿到了你Redis里存储的数据，他看到的也是一串串毫无意义的哈希值，而不是真实的密码。

仅仅使用普通的哈希算法（比如MD5或SHA-256）在今天看来已经不够安全了，因为黑客们手里有一种叫做“彩虹表”的东西，简单说，这就是一个预先计算好的、包含了海量常用密码及其对应哈希值的巨大字典，他们可以拿着你数据库里泄露的哈希值，直接去这个“字典”里反查，如果用户的密码不够复杂（123456”或“password”），就能瞬间被破解。

为了对抗彩虹表,我们需要给哈希过程“加盐”。“盐”是一个随机生成的、足够长的字符串。 它的用法是这样的：在为用户创建密码时，系统先为他生成一个独一无二的随机盐值，然后将这个盐值拼接到用户的密码前面或后面，再对整个（密码+盐）字符串进行哈希计算，将这个盐值和计算出的哈希值一起存储在Redis中。

当用户登录时,我们不是直接拿他输入的密码去Redis里匹配，而是先从Redis中取出对应账号的盐值，将用户输入的密码与这个盐值拼接，然后用同样的哈希算法计算一次，将计算出的新哈希值与Redis中存储的旧哈希值进行比对，如果两者一致，就说明密码正确。

“加盐”的好处是巨大的，即使两个用户使用了完全相同的密码，由于系统为他们生成的盐值是随机的，他们最终的密码哈希值也会是天差地别的两个字符串，这彻底废掉了黑客使用预先计算好的彩虹表进行批量攻击的可能，黑客想要破解一个密码，就必须针对这个特定的“盐+哈希值”组合，一个一个地去暴力尝试，所需的时间和计算成本呈指数级增长，这个方法是目前行业内的标准实践，被广泛应用于各种网络服务中。

我们谈谈如何在Redis中具体组织和存储这些信息,既然我们的目标是“别直接暴露用户信息”，那么除了密码，我们还应该考虑其他信息的保护，一个常见的错误是把用户的所有信息，比如用户名、邮箱、手机号、密码哈希值等都放在同一个Redis键值对里，如果这个键的名称就是用户名或用户ID，攻击者一旦入侵，就能轻松获取到大量关联信息。

一个更安全的做法是将身份标识信息和认证凭证信息分开存储，具体可以这样设计：

1. 创建两个独立的键：

   • 用户信息键：这个键用来存储可以公开或半公开的信息，比如用户ID、昵称、头像URL等，键名可以是 user:info:[用户ID]。
   • 认证凭证键：这个键只存储与登录认证相关的核心敏感信息，即密码哈希值和盐值，键名应该与用户信息键不同，可以使用一种非直接的映射关系，auth:cred:[用户ID的某种单向变换] 或者 auth:cred:[一个独立的、与用户ID无直接对应关系的随机UUID]，这样做的目的是，即使攻击者拿到了用户信息键下的所有数据，他也无法直接、轻易地找到对应每个用户的密码哈希值存放在哪里，增加了攻击的难度。

2. 控制Redis的访问权限：确保你的Redis服务器只监听在内网地址，不要暴露在公网上，为Redis设置一个强密码（requirepass配置），让你应用程序连接Redis时也需要认证，这能防止未经授权的客户端直接连接到你的Redis服务。

3. 选择强哈希算法：不要使用已经破译的MD5或SHA-1，目前推荐使用 bcrypt、scrypt 或 Argon2 这类专门为密码哈希设计的算法，它们不仅计算慢（故意设计成慢速的，以对抗暴力破解），而且占用的内存也多，使得大规模硬件并行攻击的成本非常高，大多数编程语言都有现成的库来支持这些算法。

4. 设置合理的键过期时间：对于登录会话等临时数据，一定要设置TTL（生存时间），不要让已经失效的会话数据永远留在Redis里，这可以减少数据暴露的风险。

用Redis安全地处理密码,核心要点是：使用加盐的、强度高的专用密码哈希算法（如bcrypt）对密码进行不可逆加密，并将用户身份信息与认证凭证信息在Redis中物理分离存储，配合严格的Redis服务端网络与认证配置，才能构建一个相对安全的用户认证体系，安全是一个过程，没有一劳永逸的方案，但这些基本措施能为你建立起坚固的第一道防线。