做兑换系统的兄弟十个有八个栽过同一个跟头——卡密明文往数据库里塞，图省事。等哪天数据库被人拖了库，几万张激活码裸奔着流到黑产手里，哭都来不及。这事儿说大不大说小不小，但卡密哈希加密存储这一步省不掉，今天就用大白话唠明白，为啥兑换系统的卡密不能明文进库，哈希加密又是怎么把泄露这口锅给焊死的。

卡密明文存储为啥是兑换系统的死穴

兑换系统卡密明文存进数据库，等于把保险柜钥匙挂在门把手上，数据库一漏全盘皆输，没得救。

前阵子跟软件工程师强子聊起这个兑换行业，他是做积分兑换系统的，他们公司之前卡密激活码直接明文扔数据库里，运维那边嫌加密麻烦，觉得内网够安全了。结果有回服务器配置漏了个口子，被人扫到端口直接拖了库，十几万张没核销的卡密全明文摆在那儿，跟白送没区别。第二天黑产那边就开始批量核销，他们紧急冻结都来不及。

软件工程师强子说那回光善后赔客户就花了大半年利润，更别提口碑砸了。明文存卡密这事儿，跟把所有鸡蛋放一个篮子里一个道理，篮子一翻全碎。你想想，卡密这东西跟用户密码还不一样，用户密码泄露了还能改，卡密核销掉就是核销掉了，钱已经出去了，追不回来。他们后悔死了，没用哈希加密。

卡密明文进库，不是省钱是埋雷，拖库那一刻雷就炸了。

哈希加密到底是个啥玩意儿

哈希加密就是把卡密搅成一串固定长度的乱码存进去，能验证对错但还原不回原样，数据库漏了也掏不出原卡密。

哈希这词听着唬人，其实你把它想成绞肉机就行。你扔进去一块肉（原卡密），出来一坨肉馅（哈希值），肉馅没法拼回原来的肉块。验证的时候用户输入卡密，系统再绞一遍，拿肉馅跟库里存的肉馅比，一样就是对的，不一样就是错的，整个过程压根不需要存原肉。

所以就算数据库被拖了，黑客拿到的是满屏肉馅，绞不回原始卡密。这跟加密不一样——加密是上锁还能开锁，哈希是单向绞肉，理论不可逆。常见有人拿MD5凑合，这玩意儿早被玩坏了，彩虹表一查就破，现在正经做兑换系统的都换SHA-256往上走，或者干脆上bcrypt这种慢哈希，专门治暴力破解。

哈希不是上锁是绞肉，肉馅还原不回肉块，这才是卡密存储该有的样子。

光哈希还不够，盐值这东西少不得

光哈希不加盐，同卡同哈希值容易被彩虹表批量破解，盐值就是给每张卡密单独撒把料，让绞出来的肉馅各不相同。

这事儿新手最容易漏。光哈希不加盐，等于所有用户拿同一款绞肉机绞，同样的卡密绞出来同样的肉馅。黑客拿到库，把常见卡密组合提前绞一遍存成彩虹表，一比对就破，批量秒杀。

盐值就是给每张卡密在绞之前加一串随机字符，哪怕是同一张卡密，盐不一样肉馅就不一样。这样黑客就算拖了库，也没法用通用彩虹表批量套，只能一张一张暴力算，成本直接拉满，算到天荒地老也不一定划算。正经兑换系统的卡密存储，哈希加随机盐是基本盘，少了盐这层等于裸哈希，防君子不防小人。

对了，盐别用什么时间戳、卡密前几位这种可猜的，得用密码学随机数生成器，够乱够长才行。这步偷懒的人不少，老李前年就栽在这上头，盐用卡密本身的前四位，等于没加。

哈希不加盐等于门上挂锁不挂钥匙扣，防不住会撬的，盐值是那把钥匙扣。

普通人怎么一眼看出兑换系统安不安全

问商家一句卡密怎么存的，明文存直接pass，哈希加随机盐才算及格，能说出bcrypt或SHA-256加分。

小白挑兑换系统或者商城系统，不用懂代码，问一句就行——卡密是明文存的还是哈希存的？对方要是支支吾吾或者说“我们加密了的”但说不出具体方案，这就不太靠谱。能直接说哈希加随机盐、用SHA-256或bcrypt的，至少说明技术上心。

再就是看他们出过事没有，网上搜搜有没有拖库传闻，客服对卡密安全问询的态度也能看出门道，一问就急眼的心里指定有鬼。懂行的商家张口就能答，不懂行的绕半天绕不到点上。

还有一点，预付卡、虚拟商品这类涉及客户资金和隐私的，存储方案更得较真，问清楚再做决定，别图便宜入了坑。

不会看代码就问一句卡密怎么存，答不上来的系统再便宜也别碰。

卡密这东西，明文存就是定时炸弹，哈希加盐才是正经活，拖库了也掏不出一张有效卡，这账谁算都划算。