哈希生成器
从文本生成 MD5、SHA-1、SHA-256、SHA-384 和 SHA-512 哈希值。所有算法一次性全部计算完成,使用浏览器原生的加密功能,不会传输任何内容。
- 文件永不离开你的设备
- 免费,无需注册
- 无水印
- 加载后可离线使用
如何哈希生成器
- 1
输入你的文本
输入或粘贴任何内容——哈希值会随输入即时更新。
- 2
查看结果
MD5、SHA-1、SHA-256、SHA-384 和 SHA-512 会一起显示出来。
- 3
复制
点击一下就能把任意一个哈希值复制到剪贴板。
哈希值到底能保证什么
一个密码学哈希函数接受任意大小的输入,产出固定长度的输出——SHA-256 是 256 位,无论输入是一个字符还是一 GB 数据都一样——它有两个让它变得有用的特性:同样的输入总是产出完全相同的输出,而输入哪怕只改变一个比特,也会产出一个完全不同、不可预测的输出,而不是一个略有差异的输出。这正是哈希值在验证场景中有用的原因:比较两个哈希值,能以压倒性的置信度告诉你两份数据是否完全相同,而不需要逐字节比较数据本身。
哈希函数明确不做的一件事,是以某种可以还原的方式压缩或表示数据——它在设计上就是单向函数。没有任何操作能拿一个 SHA-256 的输出反推出原始输入,这和 Base64 这类可以轻易逆转的编码方案有本质上的不同。
为什么 MD5 和 SHA-1 明明已被攻破却仍然存在
一个密码学哈希被认为"已被攻破",具体是指有人展示出了一种能比暴力破解预期更快地找到两个产生相同输出的不同输入——即碰撞——的方法。针对 MD5 的实际碰撞攻击从 2004 年起就已经存在,而针对 SHA-1 的一次真实、可行的碰撞在 2017 年被展示出来,这也是为什么这两者都不应该被信任用在任何攻击者可能蓄意伪造匹配数据的场合,比如数字签名或证书验证。
它们之所以仍在广泛使用,是出于一个范围更窄、非对抗性的目的:验证下载的文件是否匹配发布者列出的校验和,或者检测传输过程中的意外损坏。在这种场景下没有人会蓄意构造一个碰撞文件,两种算法在捕捉意外差异这件事上依然完全可靠——它们的漏洞特指的是蓄意构造的、精心设计的碰撞,而不是日常的完整性检查。
为什么原始哈希是密码场景下错误的工具
SHA-256 及其同类算法在设计上就是快速的——这个速度对于验证下载文件来说是一个优点,因为你希望校验和瞬间算出来,但对密码存储来说恰恰是一个严重的隐患,因为速度正是攻击者想要的东西。现代消费级硬件每秒能计算数十亿次 SHA-256 哈希,这意味着一份被盗的原始 SHA-256 密码哈希数据库,能以惊人的速度被暴力破解,或者对照预先计算好的表进行核查。像 bcrypt、scrypt 和 Argon2 这类专门为密码设计的哈希算法,刻意让每次尝试都很慢、计算成本很高,专门为了让同样的暴力破解攻击变得实际上不可行,即使投入相当可观的算力——这和通用校验和函数的设计目标有本质上的不同。
常见问题
MD5 用起来安全吗?
涉及安全的场合不安全。针对 MD5 的实际碰撞攻击从 2004 年起就已经存在,SHA-1 也从 2017 年起被攻破。两者在非对抗性的场合仍然有用——比如验证下载文件是否匹配公布的校验和,或者检测意外的数据损坏。只要可能存在攻击者,就该使用 SHA-256 或更强的算法。
哈希值能被还原回原始文本吗?
不能——哈希在设计上就是单向的。但很短或很常见的输入,可以通过暴力破解或预先计算好的彩虹表找到,这正是为什么密码必须用像 bcrypt 或 Argon2 这样刻意设计得很慢的加盐算法来哈希,而不能用一个原始的 SHA 算法。
我应该用这个工具给密码做哈希吗?
不应该。密码存储需要一个刻意设计得很慢、并且针对每个用户单独加盐的算法——bcrypt、scrypt 或 Argon2。原始的 SHA-256 速度太快了:现代硬件每秒能对它尝试数十亿次猜测。
我的输入会被发送到别处吗?
不会。SHA 系列哈希使用浏览器内置的 Web Crypto API,MD5 则直接在这个页面用 JavaScript 运行。没有任何内容被传输,这也是这个工具离线也能继续工作的原因。
为什么同样的文本在别处得到的哈希值不一样?
几乎总是因为多了一个换行符,或者字符编码不同。这个工具是把你输入内容按 UTF-8 精确编码后的字节做哈希——像 `echo` 这样的命令行工具,除非加上 `-n` 参数,否则会自动附加一个换行符。