打开技术新闻的评论区，总能看到把「编码」「加密」「哈希」混为一谈的发言：「我把密码 Base64 一下不就安全了？」「MD5 加密的密码怎么会泄露？」
这些误解不仅存在于外行嘴里，不少写了几年业务代码的程序员也未必真分清。今天用大白话把几个最容易混淆的概念拆开，顺便说说普通人真正该怎么做。
一、Base64 只是编码，不是加密
这是最高频的误区。很多人看到一串像 YWJjMTIz 这样的字符，就觉得「这下别人看不懂了，安全」。
其实 Base64 转换 做的事情，和「把中文翻译成拼音」差不多：它是一种编码方式，目的是让二进制数据能在只认文本的通道（比如邮件、URL）里传输，而不是为了隐藏内容。它的规则是公开的，没有任何密钥，任何人都能一键还原。
换句话说，Base64 解决的是「能不能传」的问题，不是「别人看不看得到」的问题。把密码 Base64 之后存数据库，和明文存储几乎没有区别——只要有人拿到那串字符，粘进解码框立刻原形毕露。
记住一句话：凡是「不需要钥匙就能变回去」的，都不是加密。
二、哈希是「单向」的，别指望解密
另一个常见说法：「这个哈希值被破解了，说明哈希能解密。」严格说，哈希从来就不是用来「解密」的——因为它从设计上就是单向的。
哈希函数把任意长度的数据，映射成一串固定长度的指纹。它的特性是：同样的输入永远得到同样的输出；输入差一点，输出天差地别；而且从输出几乎不可能反推出输入。
那为什么新闻里总说「哈希被破解」？通常不是数学上逆向算出来了，而是攻击者用「彩虹表」——预先算好海量常见密码对应的哈希，然后拿去比对。所以单纯的哈希（比如古老的 MD5）存密码依然不安全，正确做法是加盐（salt）后再哈希，让预计算失效。
普通人能直观感受哈希的地方，是用 文本哈希 给一段关键配置或合同摘要算个指纹，日后比对时只要指纹一致，就能确认内容没被篡改。它不隐藏信息，但能验证「完整性」。
三、对称与非对称：两把钥匙的故事
「加密」二字背后，其实有两种截然不同的思路。
对称加密像一把普通的挂锁：加密和解密用同一把钥匙。优点是快、简单；缺点是钥匙得想办法 safely 传给对方，传的过程中被截获就全完了。
非对称加密则像一把特殊的锁：你有一把「公钥」可以公开给大家用来锁东西，和一把只有你自己有的「私钥」用来开。别人用公钥加密的数据，只有你的私钥能解开。这就解决了「钥匙怎么传」的难题——公钥本来就是公开的，不怕被人知道。
我们每天用的 HTTPS、数字签名，底层都是这两套机制的组合。理解到这一层，你就明白为什么「把私钥握在自己手里」如此重要：私钥一丢，等于把锁的钥匙交给了别人。
实际要加密一段敏感文本再发送时，用 加密工具 选好算法、设好只有对方知道的密码，得到的密文即使经过不安全的渠道，没有密码也打不开——这才是真正意义上的「保护内容」。
四、HTTPS 保护的是传输，不是存储
「网站有 HTTPS 小绿锁，所以我的数据是安全的。」这句话只对了一半。
HTTPS 确保的是：你的数据从手机到服务器的这一段路上，不会被中间人偷看或篡改。它防的是「传输途中被拦截」。
但它完全不保证：服务器收到之后，会不会明文存数据库、会不会被内部人员翻阅、会不会在被拖库后泄露。换句话说，HTTPS 是「快递盒上的封条」，不是「保险柜」。封条再完好，盒子最终进了谁的仓库、怎么保管，是另一回事。
所以别因为看到小绿锁就放松对「账号密码要不要设复杂」「要不要开两步验证」这些基本动作的坚持。
五、普通人真正该做的几件事
讲了这么多原理，落到日常，其实不需要你成为密码学家，只要做对几件事：
- 密码不要用 Base64 或明文思维去「伪装」，老老实实用长随机密码 + 密码管理器。
- 别在不可信的网站输入真实敏感信息，HTTPS 只保护传输，不保护对方怎么存。
- 传输敏感内容前，先加密再发，钥匙通过别的渠道单独告知对方。
- 重要文件算个哈希留存，日后能验证没被改动。
- 开启两步验证，这是性价比最高的安全加固。
技术的细节可以不懂，但这些基本原则，能在绝大多数真实风险里保护你。
尾声
密码学听起来高深，但它在日常生活里的核心，无非是回答两个问题：「这段信息，谁能看？」「这份数据，有没有被改？」把 Base64、哈希、加密各自的边界弄清楚，你就已经避开了九成常见的认知坑。剩下的，不过是养成几个不费力的好习惯——而好习惯，正是普通人对抗风险最便宜的武器。