文章总结： 文档详解密码安全误区，指出Base64仅是编码、AES因可逆风险不适用、MD5计算过快易破解。强调密码存储必须采用随机盐配合bcrypt等慢哈希算法，传输应依赖HTTPS，确保不可逆与抗暴力破解能力。
综合评分： 95
文章分类： 安全开发,WEB安全,数据安全

登录的加密方式

原创

hack07

网络攻防研究

2025年12月29日 16:50
上海

问题1：登录密码可以用base64加密吗？

结论先说：登录密码绝对不可以只用 Base64 处理，这不是加密，是「伪加密」，等于裸奔

Base64 的本质是编码（Encoding），不是加密（Encryption），也不是哈希（Hash），这是后端 / 安全里的核心知识点，很多人都会踩这个坑。

核心区别：编码 ≠ 加密 ≠ 哈希

Base64 是「编码」

作用：把二进制数据转成可见的 ASCII 字符，方便在 URL / 表单 / 接口里传输，没有任何安全性可言。
特点：可逆，且解码成本为 0。网上随便搜一个Base64解码工具，输入密文秒出明文密码，甚至后端代码里一行atob()/new Base64().decode()就解出来了。
举例：密码123456的 Base64 是MTIzNDU2，任何人看到这个字符串，都能瞬间得到你的原始密码。

加密是「可逆的安全转换」

比如 AES、DES，加密后的数据需要密钥才能解密，有一定安全性，但依然不适合存密码。
问题：如果密钥泄露，所有密码都会被破解；且加密可逆，意味着系统里能还原出用户的明文密码，合规上也不允许（比如《网络安全法》要求禁止明文存储用户密码）。

哈希是「不可逆的摘要计算」 ✅【密码存储的正确方案】

比如 MD5 (淘汰)、SHA256、bcrypt、Argon2、PBKDF2，核心是：把明文密码转成一串乱码，无法反向还原。
登录校验逻辑：用户输入密码 → 对输入值做相同哈希计算 → 对比数据库里的哈希值，一致则登录成功。
特点：不可逆，就算数据库泄露，黑客也拿不到你的明文密码，这是行业唯一合规、安全的密码存储方式。

二、密码存储的「安全等级排行」（必看，开发直接照做）

从最不安全 → 行业标准（推荐），你可以对照自己的项目：

❌ 绝对禁止（自杀级）

明文存储密码（比如数据库存123456）
仅用 Base64 编码存储（和明文没区别）
仅用 MD5/SHA1/SHA256 纯哈希存储（彩虹表能秒破，比如123456的 MD5 是固定值e10adc3949ba59abbe56e057f20f883e）

⚠️ 勉强能用（入门级，不推荐）

纯哈希 + 固定盐值（Salt）

比如：哈希(密码 + 固定字符串)，能防彩虹表，但如果盐值泄露，依然会被批量破解。

✅ 强烈推荐（企业级，行业标准）

哈希 + 随机盐值 + 慢哈希算法，三要素缺一不可：

随机盐值

给每个用户生成一个唯一的随机字符串，和密码拼接后再哈希，盐值和哈希结果一起存在数据库。
慢哈希算法

选择 bcrypt / Argon2 / PBKDF2 这类算法，故意把哈希计算变慢（比如计算一次需要 0.1 秒），黑客就算拿到数据库，暴力破解的成本也会指数级上升。

❌ 不要用 MD5/SHA256 做密码哈希，它们是「快哈希」，专门用于文件校验，暴力破解速度极快。

四、补充：前后端密码传输的安全规范

很多人担心：前端传密码的时候，会不会被中间人抓包？这里给 2 个必须落地的规则，优先级分先后：

✅ 第一优先级（重中之重）：全站开启 HTTPS

HTTPS 会对整个请求体做对称加密，就算被抓包，拿到的也是密文，这是传输层面的绝对安全，比前端做任何加密 / 编码都管用。

结论：只要开了 HTTPS，前端直接传明文密码都安全，Base64 编码只是「锦上添花」，不是必需。

✅ 第二优先级（锦上添花）：前端可选处理

开了 HTTPS：前端无需做任何处理，直接传明文密码即可。
没开 HTTPS（测试环境）：可以用 Base64 编码后传输，或者用 RSA 加密后传输，避免明文暴露。

总结：一句话记住所有要点

Base64 编码 ≠ 加密，密码存储必须用「随机盐 + 慢哈希」，密码传输必须开 HTTPS

常见误区纠正

❌ 误区：用 Base64 加密密码，别人就看不到了。 → ✅ 正解：Base64 是编码，任何人都能解码，等于裸奔。
❌ 误区：MD5 加密密码很安全。 → ✅ 正解：MD5 是哈希不是加密，纯 MD5 哈希的密码，彩虹表秒破。
❌ 误区：前端加密后，后端就不用哈希了。 → ✅ 正解：前端所有加密逻辑都是「防君子」，后端必须做哈希，这是最后一道、也是最核心的安全防线。

后端密码哈希的极简示例（Java/Node.js）

1. Node.js 示例（bcrypt，最常用）

const&nbsp;bcrypt =&nbsp;require('bcrypt');const&nbsp;saltRounds =&nbsp;10;&nbsp;// 越大越慢，推荐10-12// 注册：密码哈希存储const&nbsp;password =&nbsp;'123456';bcrypt.hash(password, saltRounds,&nbsp;(err, hash) =>&nbsp;{&nbsp;&nbsp;// hash就是要存入数据库的密文，比如 $2b$10$xxxxxxxxx&nbsp;&nbsp;console.log(hash);});// 登录：校验密码const&nbsp;inputPwd =&nbsp;'123456';const&nbsp;dbHash =&nbsp;'$2b$10$xxxxxxxxx';&nbsp;// 从数据库查出来的哈希值bcrypt.compare(inputPwd, dbHash,&nbsp;(err, res) =>&nbsp;{&nbsp;&nbsp;console.log(res);&nbsp;// true=密码正确，false=密码错误});

2. Java 示例（BCrypt，SpringBoot 推荐）

import&nbsp;org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;BCryptPasswordEncoder&nbsp;encoder&nbsp;=&nbsp;new&nbsp;BCryptPasswordEncoder();// 注册：哈希密码String&nbsp;password&nbsp;=&nbsp;"123456";String&nbsp;hash&nbsp;=&nbsp;encoder.encode(password);// 存入数据库// 登录：校验密码boolean&nbsp;isMatch&nbsp;=&nbsp;encoder.matches("123456", hash);&nbsp;// true

问题2：为什么AES仍然不适合作为登录的密码加密方式？

核心结论：AES 不适合密码存储的核心原因是「可逆性」—— 密码存储的核心诉求是「不可逆、无法还原明文」，而 AES 的设计目标是「可逆加密」，两者从根上冲突

AES（高级加密标准）是对称加密算法，本身是非常安全的加密方式，但它的设计场景是「需要还原原始数据的加密传输 / 存储」（比如加密用户手机号、身份证号），而非「无需还原、仅需校验的密码存储」。用 AES 存登录密码，会带来不可逆的安全风险和合规问题，具体拆解如下：

一、AES 不适合密码存储的 4 个致命问题

1. 最根本：AES 可逆，违背密码存储的「不可逆」核心原则

密码存储的终极目标是：就算数据库泄露、甚至服务器被攻破，黑客也无法获取用户的明文密码。

哈希算法（bcrypt/Argon2）：把密码转成「不可逆的摘要」，只能 “校验输入密码是否匹配”，永远无法从摘要还原出明文；
AES 加密：把密码转成「可逆的密文」，只要拿到密钥，就能瞬间解密出明文密码。

举个极端例子：

用 bcrypt 哈希的密码库泄露：黑客拿到的是一串乱码，暴力破解只能 “猜密码→算哈希→对比”，慢哈希算法能把这个过程拖到成本极高；
用 AES 加密的密码库泄露：只要黑客同时拿到加密密钥（比如从后端配置文件里找到），所有用户的明文密码会被一次性批量破解，相当于裸奔。

2. 密钥管理是 “定时炸弹”，无法根除风险

AES 是对称加密，必须依赖「密钥（Key）」—— 加密和解密用同一个密钥，这个密钥的存储和管理是无解的难题：

密钥存在哪里？如果存在后端代码、配置文件、环境变量里，一旦服务器被入侵，密钥会被直接窃取；如果存在数据库里，和加密后的密码 “同库存储”，黑客拿到数据库就等于同时拿到密文 + 密钥；
密钥是全局的：AES 密钥通常是系统级的（一个密钥加密所有用户密码），一旦泄露，所有用户密码全部沦陷；而哈希 +「随机盐」是用户级的，每个用户的盐值唯一，就算盐值泄露，也只能逐个破解，成本指数级上升。

3. 违反合规要求，面临监管风险

各国网络安全法规（如中国《网络安全法》《个人信息保护法》、欧盟 GDPR）都明确要求：

「禁止明文存储、传输用户密码，且不得具备还原用户明文密码的能力」

用 AES 加密密码的系统，本质上依然 “具备还原明文密码的能力”（只要有密钥），属于违规操作。一旦被监管抽查发现，企业会面临罚款、整改，甚至停业风险；而哈希算法从逻辑上就无法还原明文，完全符合合规要求。

4. 登录校验逻辑冗余，额外增加攻击面

登录的核心逻辑是「校验一致性」，而非「还原明文」：

哈希的校验逻辑（安全）：用户输入密码 → 计算哈希摘要 → 对比数据库中的哈希值（全程不碰明文）；
AES 的校验逻辑（危险）：要么「用户输入密码→AES 加密→对比数据库中的 AES 密文」（需前端 / 后端持有密钥，密钥泄露风险），要么「数据库中 AES 密文→解密成明文→对比用户输入的明文」（解密过程可能被劫持，明文暴露）。

两种 AES 校验逻辑都多了「密钥持有 / 解密」的步骤，既没有提升安全性，反而增加了攻击面（比如密钥被劫持、解密接口被调用）。

二、补充：别混淆「AES 的正确场景」和「密码存储场景」

AES 不是 “不安全”，而是「用错了地方」：

比如：你可以用 AES 加密用户的收货地址（需要还原给用户看），但绝对不能用 AES 加密用户的登录密码（永远不需要还原）。

三、对比：AES vs 慢哈希（bcrypt），为什么慢哈希是唯一解？

四、常见误区纠正

❌ 误区 1：“AES 加密比哈希安全，用 AES 存密码更保险”

✅ 正解：安全的算法用错场景 = 不安全。AES 的 “安全” 是针对「可逆加密」场景，而密码存储需要「不可逆摘要」，哈希才是适配场景的方案。

❌ 误区 2：“我把 AES 密钥藏得很好，就不会泄露”

✅ 正解：“藏密钥” 是「安全通过隐藏」，而哈希是「安全通过设计」。只要系统需要解密密码，密钥就必须存在于运行环境中，总有被窃取的可能（比如运维权限、漏洞攻击、内部人员泄露），而哈希从设计上就没有 “密钥” 这个风险点。

❌ 误区 3：“登录时用 AES 加密输入密码，对比密文不就不用解密了？”

✅ 正解：这种逻辑看似绕开了解密，但本质问题没解决：

前端必须持有 AES 密钥才能加密输入密码，密钥会随前端代码暴露（比如前端 JS 里的密钥能被扒出来）；
就算前端加密，黑客依然可以 “暴力枚举密码→AES 加密→对比库中密文”，而 AES 是高速算法，枚举速度和破解纯 MD5 差不多，远快于慢哈希。

问题3：md5是hash算法吗？

✅ 结论：MD5 百分百是 Hash（哈希 / 散列）算法，而且是最经典的哈希算法之一

99% 的开发者都会踩的核心误区：

MD5 是哈希算法，但哈希 ≠ 加密，且 MD5 这类「快哈希」完全不适合做密码存储，这和之前的 AES、Base64 刚好能串成完整的知识体系。

一、4 个概念彻底分清（重中之重）

Base64、AES、慢哈希，现在加上 MD5，这四个是密码场景里最容易混淆的 4 个概念：

✅ 1. Base64 → 编码（Encoding）

本质：格式转换工具，无安全属性，可逆；
目的：把二进制转成可见字符，方便传输；
总结：不是加密、不是哈希，就是个翻译器。

✅ 2. AES → 加密（Encryption）

本质：可逆的安全转换，对称加密算法，有密钥；
目的：加密需要还原的敏感数据（手机号 / 身份证）；
总结：可逆、有密钥、能还原明文，适合隐私数据，不适合密码。

✅ 3. MD5/SHA1/SHA256 → 哈希（Hash）→ 「快哈希」

本质：不可逆的摘要计算，无密钥，属于哈希算法；
目的：校验数据完整性（文件是否被篡改、内容是否一致）；
核心特征：计算速度极快（一秒能算上亿次），不可逆；
总结：是哈希，但不适合密码存储。

✅ 4. bcrypt/Argon2/PBKDF2 → 哈希（Hash）→ 「慢哈希」

本质：不可逆的摘要计算，无密钥，也属于哈希算法；
目的：专门为密码设计的哈希算法；
核心特征：故意把计算速度变慢（算一次 0.1 秒），不可逆；
总结：是哈希，也是密码存储的唯一正确选择。

二、既然 MD5 是哈希算法，为什么绝对不能用来存密码？

这是核心问题，也是面试必问考点：MD5 是哈希，哈希是不可逆的，那为什么存密码不行？

MD5 的问题不是「是不是哈希」，而是它属于 「快哈希」，设计初衷就不是为密码而生，它的 3 个致命缺陷，让它在密码场景里形同裸奔，就算加盐也没用：

❌ 缺陷 1：MD5 是「快哈希」，暴力破解成本为 0

哈希算法的不可逆，指的是无法从哈希值反向推导明文，但黑客可以用「正向暴力枚举」：

逻辑：猜密码 → 用 MD5 算哈希值 → 和数据库里的哈希值对比，匹配就是正确密码；
MD5 的问题：计算速度太快了，普通电脑一秒钟能对 MD5 做上亿次哈希计算，黑客用彩虹表 / 字典库，能在几秒钟内破解123456、admin、111111这类弱密码，哪怕是复杂密码，也能被算力破解。
对比慢哈希（bcrypt）：bcrypt 故意把计算速度放慢，算一次哈希需要0.1 秒，同样的暴力破解，时间成本直接翻百万倍，这就是慢哈希的核心价值。

❌ 缺陷 2：MD5 的哈希值极易碰撞 + 已被破解

哈希算法的理想特性是：不同的明文，绝对不能算出相同的哈希值（唯一性）。

但 MD5 在 2004 年就被数学证明存在哈希碰撞漏洞：两个完全不同的明文，可以算出一模一样的 MD5 哈希值。

比如：明文 A 是123456，明文 B 是一串乱码，但两者的 MD5 值都是e10adc3949ba59abbe56e057f20f883e，这意味着黑客可以构造假密码匹配真哈希，直接绕过校验，安全性彻底失效。

补充：SHA1 也被破解了，SHA256 暂时安全，但SHA256 也是快哈希，同样不适合存密码！

❌ 缺陷 3：就算给 MD5 加盐，也只是「亡羊补牢」，治标不治本

很多人觉得：我给 MD5 加个盐，MD5(密码+盐值)，是不是就安全了？

答案是：依然不安全，只是稍微提升了一点破解成本。

加盐能防「彩虹表」（黑客提前算好的密码 – 哈希对照表），但防不住暴力枚举；
如果你的盐值是固定盐（比如所有用户都用同一个盐），黑客只要拿到盐值，就能批量破解所有用户密码；
就算是随机盐，MD5 的计算速度依然太快，黑客可以针对每个用户的盐值单独暴力破解，只是时间久一点而已；
反观慢哈希（bcrypt）：自带随机盐值 + 慢计算，盐值会被嵌入到最终的哈希结果里，数据库存一份就够，这是从算法层面解决问题，而不是补丁。

三、MD5 的「正确用法」：它不是废物，只是用错了地方

MD5 虽然绝对不能存密码，但它作为经典哈希算法，在非密码场景里依然是王者，而且是开发中高频使用的，它的设计初衷就是这些场景，用对地方就是神器：

✅ 1. 校验文件完整性：下载软件 / 安装包时，官网会给一个 MD5 值，你下载后对文件算 MD5，和官网的一致，就说明文件没被篡改、没中毒；✅ 2. 文件去重：网盘 / 相册的「相似图片去重」「重复文件删除」，就是用 MD5 计算文件哈希值，相同哈希就是相同文件；✅ 3. 生成短唯一标识：给文章、图片、订单生成一个简短的唯一 ID，用 MD5 哈希后截取部分字符，高效又方便；

✅ 4. 接口防篡改：接口传参时，把参数拼接后算 MD5，后端校验 MD5 值，防止参数被中间人篡改。

✅ 一句话总结 MD5 的使用边界：能用 MD5 做的，绝对不要用加密；需要存密码的，绝对不要用 MD5。

四、补充：哈希算法的「派系划分」

所有哈希算法都分两大派系，没有好坏之分，只有场景适配与否，记住这个分类，你就是团队里的安全专家：

✅ 第一派系：快哈希 → 代表：MD5、SHA1、SHA256、SHA512

核心特征：计算速度极快，哈希值固定长度；
设计目的：校验数据完整性、生成摘要、去重、标识；
绝对禁忌：禁止用于密码存储。

✅ 第二派系：慢哈希 → 代表：bcrypt、Argon2、PBKDF2

核心特征：故意放慢计算速度，支持动态调整计算耗时；
设计目的：专门为密码 / 支付密码 / 验证码等敏感口令设计；
唯一适用：用户密码的哈希存储，这是行业标准，没有之一。

五、终极总结：

结合之前的 Base64、AES、慢哈希，加上今天的 MD5，把所有密码安全的核心原则浓缩成5 句话，看完这 5 句话，你对密码安全的理解就超过 90% 的开发者：

Base64 是编码，不是加密 / 哈希，无安全价值，仅做格式转换

；
AES 是加密，可逆有密钥，适合加密需要还原的隐私数据，不适合密码

；
MD5 是哈希（快哈希），不可逆，适合数据校验，绝对不适合密码存储

；
bcrypt/Argon2 是哈希（慢哈希），不可逆，是密码存储的唯一正确方案

；
密码传输的核心是 HTTPS，前端任何加密 / 编码都是锦上添花，后端哈希才是最后防线

。

问题4：就算是随机盐，MD5 的计算速度依然太快，黑客可以针对每个用户的盐值单独暴力破解，只是时间久一点而已；就算慢hash不还是时间久一点吗？

「随机盐 + MD5」和「bcrypt/Argon2 慢哈希」，本质上都是让黑客破解的「时间变久」，但两者的区别，不是「久一点 vs 久很多点」，而是：

✅ MD5 的「久」 → 黑客咬咬牙能破解，只是费点时间

✅ 慢哈希的「久」 → 黑客就算砸光家底买超级算力，也破解不了，时间久到「失去任何意义」

这个差距的本质，是 「量变引发的绝对质变」 —— 这个时间差的量级，是「百万倍、千万倍、甚至亿倍」，而且是算法层面的先天差距，黑客用任何硬件都补不回来，这也是为什么慢哈希是行业唯一标准答案，而 MD5 哪怕加盐也被彻底淘汰。

一、先讲核心前提：黑客破解密码，从来不是「破解 1 个用户」，而是「破解全库用户」

你思考的是「单个用户的密码破解时间」，但真实的黑客攻击场景里：

数据库泄露后，黑客手里是几百 / 几千 / 几万条用户数据（密码哈希 + 盐值），他的目标是尽可能多的破解出用户明文密码，而不是盯着 1 个用户死磕。

这个场景下，「计算速度」的微小差距，会被「批量破解」无限放大，这是理解所有问题的基础。

二、核心本质：MD5 的「快」和慢哈希的「慢」，是【算法层面的天壤之别】，不是「差一点」

✅ 先看一组真实、直观的算力对比（普通家用电脑）

这组数字是密码安全的黄金数据，背下来你就彻底懂了，没有任何模糊空间：

MD5（快哈希）

：1 秒钟能计算 ≈ 1 亿次 MD5 哈希

哪怕加了随机盐，计算逻辑是MD5(密码+随机盐)，这个速度也几乎不变，还是一秒上亿次。

bcrypt（慢哈希，行业标准 cost=10）

1 秒钟只能计算 ≈ 10 次 bcrypt 哈希
Argon2（新一代慢哈希，标准配置）

1 秒钟只能计算 ≈ 5 次 Argon2 哈希

✅ 这个差距意味着什么？【百万倍的时间鸿沟】

我们用最常见的弱密码（比如 6 位数字密码：123456） 举例，黑客暴力枚举所有可能性（000000~999999，共 100 万种组合）：

随机盐 + MD5

破解这 100 万种组合，需要的时间 = 100万 ÷ 1亿 = 0.01秒→ 眨眼之间，黑客就破解了这个用户的密码。
bcrypt 慢哈希

破解这 100 万种组合，需要的时间 = 100万 ÷ 10 = 10万秒 ≈ 27.8小时→ 黑客要对着这一个用户，不眠不休算 1 天多，才能破解。

如果密码是稍复杂的 8 位混合密码（数字 + 字母），组合数是62^8 ≈ 218万亿：

随机盐 + MD5

算完需要 ≈ 69 年（普通电脑），但黑客可以用显卡集群 / 云算力，几十块显卡并行计算，几天就能破解。
bcrypt 慢哈希

算完需要 ≈ 6900 万年。→ 这个时间，已经超过了人类文明的历史，破解这件事，从「技术问题」变成了「不可能的问题」。

三、关键补充 1：MD5 的「随机盐」，只是「防住了彩虹表」，但防不住暴力枚举，而且有致命短板

你之前看到的「加随机盐能提升 MD5 安全性」，这句话只对了一半：

✅ 加盐的唯一作用：防彩虹表

彩虹表：黑客提前用服务器算好的「明文密码 – MD5 哈希」对照表，比如123456 → e10adc3949ba59abbe56e057f20f883e，拿到数据库直接查表，0 秒破解。
加随机盐后：每个用户的盐值不同，MD5(123456+盐A) 和 MD5(123456+盐B) 的哈希值完全不同，彩虹表彻底失效。

❌ 加盐的致命短板（MD5 永远补不上的漏洞）：

加盐不改变 MD5 的「快」

加盐只是在计算哈希前多拼了一串字符，对计算速度几乎没有影响，黑客依然能一秒算上亿次。
随机盐是「用户级」的，会让黑客「并行破解」，但成本极低

比如数据库有 1000 个用户，每个用户的盐值都不同，黑客只需要开 1000 个线程，同时对 1000 个用户分别暴力枚举，MD5 的快速度，让这种并行破解的成本几乎可以忽略。而慢哈希的「慢」，让这种并行破解直接失效 ——1000 个线程同时算 bcrypt，1 秒钟也只能算 10000 次，破解速度还是慢到离谱。

四、关键补充 2：慢哈希的「慢」，是故意设计的、可升级的、抗算力的慢，MD5 的「快」是天生的、不可逆的快

这是最核心的一点，也是慢哈希能成为行业标准的核心灵魂，分两层讲，特别重要：

✅ 第一层：慢哈希的「慢」，是算法层面的主动设计，不是「代码写得慢」

MD5/SHA256 这类快哈希，设计初衷是「校验数据完整性」，所以追求极致的快 —— 比如你下载一个 10G 的安装包，用 MD5 算哈希，1 秒钟就能出结果，校验文件是否被篡改。

而 bcrypt/Argon2/PBKDF2 这类慢哈希，设计初衷就是「对抗暴力破解」，所以算法里加入了大量的循环、迭代、内存消耗，比如：

bcrypt：会把哈希计算的过程重复 2^cost 次（cost=10 就是 1024 次），而且是串行循环，无法用显卡并行加速；
PBKDF2：会把哈希计算迭代10 万次以上，同样是串行，算力再强也没用。

这种慢，是算法的基因，黑客就算拿到超级计算机，也只能老老实实一步步算，无法提速。

✅ 第二层：慢哈希的「慢」，是可以动态升级的，能对抗未来的算力提升

这是慢哈希最牛的一点，MD5 完全没有这个能力：

bcrypt 有一个cost值（默认 10），cost 值每 + 1，计算时间就翻倍；如果未来显卡算力提升 10 倍，我们只需要把 cost 值调到 13，破解时间就又会翻 8 倍，永远让黑客追不上。
MD5 的计算速度是固定死的，硬件越好，破解越快 —— 现在的显卡算力比 10 年前提升了 100 倍，MD5 的破解速度也快了 100 倍，而慢哈希只需要调一个参数，就能把这个算力提升抹平。

✅ 一句话总结：MD5 的安全，会被硬件算力的提升慢慢磨掉；慢哈希的安全，能跟着算力提升同步升级，永远立于不败之地。

五、真实场景暴击：99% 的用户，密码都是「弱密码」

我们讲了这么多理论，最后回归到最真实的开发场景，你就知道为什么 MD5 加盐也没用了：

行业统计：90% 以上的用户，设置的密码都是弱密码 —— 123456、admin、手机号后 6 位、生日、姓名拼音，这些密码的组合数，撑死也就几十万种。

对这类弱密码：

随机盐 + MD5

黑客一秒算上亿次，几秒钟就能把全库的弱密码用户全部破解，剩下的复杂密码用户，能破解多少算多少，血赚不亏；
慢哈希

黑客就算只破解一个弱密码用户，也要算几十分钟，破解全库的弱密码用户，需要几个月甚至几年，破解的成本远大于收益，黑客会直接放弃，转头去攻击其他用 MD5 的网站。

这就是最现实的结果：慢哈希不是「绝对安全」，而是让黑客觉得「破解你这个网站，性价比太低，不值得」，这就足够了。

六、终极对比：随机盐 + MD5 VS bcrypt 慢哈希（核心差异表）

为了让你一眼看懂，我把所有核心差异做成表格，这也是面试的标准答案，看完彻底封神：

#

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：网络攻防研究 hack07《登录的加密方式》

Tags: WEB安全安全开发数据安全

你可能错过

WordPress 7.1.1 修复了 11 个安全漏洞，包括存储型 XSS 和路径遍历漏洞

微软前研究员亲手关掉 Defender：BigDiskBuster 让杀毒软件”装死”成现实

OpenAI智能体未经授权访问澳大利亚政府网站

OSSFileBrowse：红队渗透测试中的存储桶遍历漏洞利用神器