百科问答小站 logo   百科问答小站
问题

服务器保存用户密码的方式都有哪些？

回答
服务器保存用户密码，说起来简单，但背后涉及的学问可不少。毕竟，密码可是用户数字身份的“钥匙”，保管不好，后果不堪设想。我们来聊聊服务器都使了哪些招数来“呵护”这些密码。

1. 直接存储（❌ 绝对禁止！）：

最最基础、也是最最愚蠢的方式，就是把用户输入的密码原封不动地存进数据库。想想看，如果数据库泄露了，所有用户的密码就赤裸裸地暴露在坏人眼前。这就像把家门钥匙直接挂在门口的公告栏上，脑残到家了。所以，除非是某个年代久远、毫无安全意识的系统（请远离！），否则现在服务器绝对不会这么干。

2. 加密存储（✅ 基础操作）：

既然不能明文存储，那我们就给它“加密”一下。加密就像给密码加一道锁，只有知道“钥匙”的人（也就是服务器）才能解开。

对称加密： 顾名思义，就是加密和解密用的是同一把“钥匙”。想象一下，你把信写好，然后用一把锁锁上，再把这把锁和钥匙一起交给朋友。朋友收到后，用同一把钥匙就能打开。
常见的算法： DES, 3DES, AES (Advanced Encryption Standard)。AES 是目前最主流、最安全的对称加密算法之一。
优缺点： 加密和解密速度都比较快。但问题在于，这把“钥匙”怎么安全地管理？如果服务器内部存储这把钥匙的数据库也被攻破了，那所有加密的密码也就不安全了。

非对称加密（公钥/私钥加密）： 这就好玩了，它用的是两把“钥匙”：一把公钥，一把私钥。公钥就像一个开放的信箱，任何人都可以往里面投信（加密），但只有拥有私钥的人才能打开信箱取出信件（解密）。
应用场景： 理论上可以用来加密密码，但因为速度较慢，通常不直接用于大规模用户密码的加密。更多是用于其他安全场景，比如身份验证。

3. 哈希（Hash）存储（✅ 主流且推荐）：

这可能是我们最常听到，也是最推荐的一种方式。哈希（Hash）更像是一种“单向的指纹”技术。它把任意长度的输入，通过一个特定的算法，生成一个固定长度的、独一无二的“指纹”。

哈希的特性：
单向性： 从哈希值反推出原始密码几乎是不可能的。就像你无法根据一个人的指纹猜出他的DNA序列一样。
雪崩效应： 原始密码哪怕只有一个字母变动，生成的哈希值也会天翻地覆。
确定性： 相同的输入，总是生成相同的哈希值。

常见的哈希算法（早期）： MD5, SHA1。注意： 这两种算法现在已经被认为不够安全，不应再用于存储密码。它们容易受到“彩虹表”攻击。

安全的哈希算法（现代）：
加盐哈希（Salting）： 这是目前最基本、最重要的一步。我们给每个用户的密码在哈希之前，随机生成一个“盐”（Salt），然后把这个“盐”和密码混合在一起再进行哈希。
为什么要加盐？ 即使两个用户的密码是相同的（比如都是“123456”），由于他们各自的“盐”不同，最终生成的哈希值也会完全不同。这样就完全杜绝了彩虹表攻击。彩虹表是预先计算好的大量密码及其哈希值的对照表，如果有两个用户的哈希值一样，攻击者就可以直接用彩虹表找到对应的密码。加盐后，彩虹表就失效了。
盐怎么保存？ 盐通常会和哈希值一起保存在数据库里。因为盐本身不涉及敏感信息，而且对破解密码毫无用处。

密钥拉伸（Key Stretching）/迭代哈希： 这是一种让哈希过程变慢的技术。攻击者想要破解哈希密码，需要进行大量的计算。如果哈希算法本身很快，攻击者就能在短时间内尝试很多密码。密钥拉伸就是通过多次重复哈希过程（比如将密码哈希10万次），大幅增加计算量，让攻击者破解的成本变得非常高。
常见的算法：
PBKDF2 (PasswordBased Key Derivation Function 2): 这是一个标准，通过循环迭代哈希算法（如SHA256）来生成密钥。
BCrypt: 专门为密码哈希设计的算法，它内置了“工作因子”（work factor），可以控制哈希的计算强度，并且会自动进行“加盐”。
Scrypt: 另一个更现代的密码哈希算法，它除了计算密集性，还引入了内存密集性，进一步增加了攻击者的难度。
Argon2: 这是密码哈希竞赛的获胜者，被认为是目前最安全的密码哈希算法之一，它结合了计算密集性、内存密集性和并行性。

4. 令牌化（Tokenization）（✅ 另一种安全策略）：

令牌化通常不直接用于存储密码本身，而是用来替代敏感数据。比如，在用户登录成功后，服务器会生成一个包含用户信息的“令牌”（Token），然后将这个令牌返回给用户的浏览器或客户端。之后，客户端在进行后续操作时，就携带这个令牌，而不再需要每次都发送密码。

工作原理：
1. 用户输入密码登录。
2. 服务器验证密码正确后，生成一个随机的、唯一的令牌。
3. 令牌可以包含用户ID、过期时间等信息，并且通常会进行签名（用私钥加密，确保不可篡改）。
4. 服务器将令牌返回给客户端。
5. 客户端存储令牌，并在每次请求时携带。
6. 服务器收到请求时，验证令牌的有效性（检查签名、过期时间等），如果有效，就认为用户已经认证。

优点： 用户的实际密码不会在客户端和服务器之间反复传输，也减少了在服务器端直接暴露密码的风险。令牌通常有过期时间，即使令牌泄露，也只能在短时间内有效。

缺点： 令牌本身也需要妥善保管，如果存储令牌的数据库泄露，也会带来安全风险。

总结一下，服务器保存用户密码的“进化史”和主流做法：

过去（不推荐）： 明文存储 (❌)
早期（已不安全）： MD5/SHA1 加密 (❌)
现在（基础）： 加盐哈希 (✅)
现在（主流且推荐）： 加盐 + 密钥拉伸/迭代哈希 (如 PBKDF2, BCrypt, Scrypt, Argon2) (✅✅✅)
辅助安全手段： 令牌化 (✅)

关键点：

1. 绝不存储明文密码。
2. 使用安全的哈希算法。
3. 为每个密码生成独一无二的“盐”。
4. 使用密钥拉伸/迭代哈希来增加计算难度。
5. 定期审查和更新所使用的加密和哈希算法。
6. 数据库安全至关重要，即使是哈希值和盐，一旦泄露也是巨大的风险。

简单来说，服务器保存密码就像给宝贝锁上一层又一层保险，而且越“慢”越安全，因为慢意味着攻击者破解的成本极高。选择哪种具体算法，还要看项目的安全需求、性能要求以及开发团队的经验。

网友意见

user avatar

明文存储

最初的时候，服务器存储的都是用户的明文密码。

当然啦，也不一定是最初，比如CSDN，就属于最近的那种，即使搞个MD5加密这种最简单的保护方法，它也没做。

暴力穷举

明文密码遇到的第一个问题，就是暴力穷举。

如果密码的长度不够，例如只有五六位，那么将所有可用作设置密码的字符进行排列组合，就可以暴力破解了。

当然，这种方法也好办，只需要设置较长的密码位数就可以解决了。

暴力破解的核心是枚举，这种算法的弱点是口令空间巨大，所需的破解时间难以忍受。例如，在现有的128个ASCII字符中，有96个字符可随机选择用于设置口令。假设密码设置为10位长度，那么进行口令破解时所需要穷举的次数便是，如果使用普通的PC机来破解的话，所需要的时间就会极大，更何况，客户端与服务端进行通信过程和口令验证本身，也是需要大量时间消耗的。

不过，问题在于，人类设置口令时是有一定的行为习惯和规律的，不可能设置的和自己毫无关系，因为用户自己也需要记。后续有文章提出观点并证明：只要密码仍然是人类难以忘记的，即使潜在密码的空间很大，它们也容易受到“智能字典”攻击。

字典攻击

这就是明文密码的第二个问题——“字典攻击”。

例如，黑客可以把常见的数字和单词以及其大小写和缩写进行不同的排列组合，还可以发现用户在设置口令时的行为习惯和规律特征，并分析口令和用户个人信息之间的关系，来有针对性的设置口令破解字典规则，这样做可以大大减少破解所需要的空间。

其次，现在互联网论坛和一些地下黑客论坛都有一些之前泄露的密码数据库可以购买，黑客也可以基于先前公开的密码来进行针对破解或者撞库，这种“字典攻击”的成功率可能比上段中单纯的排列组合要更高。

不过，无论是“暴力破解”还是“字典攻击”，都逃不开一个问题，那就是必须得多次尝试，尝试的次数是一个惊人的数字。这时候服务器只需要设置一个简单的登录间隔时间（例如60s一次）或者是登录错误的次数限制（例如银行卡连续三次输入密码错误会锁卡），就可以很轻易的制裁“暴力破解”和“字典攻击”了。

哈希存储

在客户端的爆破猜测被制裁之后，很多人将目光锁定在了服务器这一端，因为无论什么情况，用户输入的密码总是要和服务器存储的密码作比较才能判断正确与否的。

所以，如果能拿到服务器上存储的用户密码，那自然可以做到轻易登录他人账号了。

因此，保存用户的密码的方式变为了哈希存储。

哈希函数的值域是很大的，定义域稍微的改动会造成哈希值至少一半二进制位的改动，因此黑客不可能会去试图穷举整个值域来破解密码。

在得到服务器上经过哈希加密后的用户口令后，虽然不可以暴力破解，但是攻击者可以用相同的哈希函数来重复一遍加密过程，来得到用户的真是密码。

另外，利用“彩虹表”这种{明文：密码}对应值的数据库，可以涵盖大部分的短密钥空间，如果用户密码的长度和复杂度不够高，那么破解密码明文就只是一个时间问题，而且这个时间不会很长。

加盐哈希

如何抵抗“彩虹表”攻击呢？

靠用户自觉设置复杂度很高且位数很长的密码是不现实的

那么，该如何解决这个问题呢？

答案是：服务端帮你增加复杂度

如果用户的密码不再等于他的输入，而是等于他的输入+服务端随机长度的一段字符，那么就会将复杂度提高，且这个值是完全随机的，没法预测，这会极大增加黑客破解数据库的复杂度。

这个所谓的“服务端随机长度的一段字符”，就被称为是加“盐”。

类似的话题

本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有

服务条款
联系我们
关于我们
隐私政策
友情链接
知乎
百度问答
搜狐
新浪