加密技术的未来：从服务端密码存储到用户数据加密方案

经作者授权转载，原文链接，作者：Roronoa Zoro

本文主要讲常见场景的数据加密方案，以及对未来加密技术的展望，先看几条新闻：

Facebook 明文存储用户密码：

Hundreds of millions of Facebook users had their account passwords stored in plain text and searchable by thousands of Facebook employees — in some cases going back to 2012, KrebsOnSecurity has learned. Facebook says an ongoing investigation has so far found no indication that employees have abused access to this data.

早在 2012 年，Facebook 明文存储数亿用户的账户密码，成千上万的 Facebook 的员工可以随意进行搜索…

原文：Facebook Stored Hundreds of Millions of User Passwords in Plain Text for Years

CSDN 600万用户账号密码泄露：

北京时间12月21日晚间消息，中国开发者技术在线社区CSDN今晚发表声明，就“600万用户账号密码泄露”一事公开道歉，承认部分用户账号面临风险，将临时关闭用户登录，并要求“2009年4月以前注册的帐号，且2010年9月之后没有修改过密码”的用户立即修改密码。

原文：CSDN详解600万用户密码泄露始末：暂关闭登录

为什么不能明文存储密码

很多新手程序员都是这样存储密码的：

username	phone	password
小明	18888888888	asd123456
大明	17777777777	123abc!@#

为什么这样做是不安全的？

首先，如果遇到数据泄露事件，明文密码直接将用户隐私暴露在空中，任何人可以登陆暴露密码的账号，随意更改。其次，即使不会泄露，内部员工也可以轻易访问用户的明文密码，当公司上了规模，你无法保证公司内部没有坏人，他们是否会搜索某些用户的密码，侵犯用户隐私。所以明文存储密码是绝对不安全的。

即使你用了这样的密码：ppnn13%dkstFeb.1st（娉娉袅袅十三余，豆蔻梢头二月初），明文存储，安全性也是木有的。

再复杂的密码， 也敌不过CSDN的明文

来自知乎用户：Right Here

题外话：历史上最有名的电脑密码是什么？

密码	含义
FLZX3000cY4yhx9day	飞流直下三千尺，疑似银河下九天
hanshansi.location()!∈[gusucity]	姑苏城外寒山寺
hold?fish:palm	鱼和熊掌不可兼得
Tree_0f0=sprintf(“2_Bird_ff0/a”)	两个黄鹂鸣翠柳
csbt34.ydhl12s	池上碧苔三四点，叶底黄鹂一两声
for_$n(@ RenSheng)_$n+=“die”	人生自古谁无死
while(1)Ape1Cry&&Ape2Cry	两岸猿声啼不住
doWhile(1){LeavesFly();YangtzeRiverFlows()};	无边落木萧萧下，不尽长江滚滚来
dig?F*ckDang5	锄禾日当午

如何存储 & 检查密码

既然密码不能明文存储，那怎么存储才是安全的？我如何检查用户输入的密码是正确的？

存储相关信息用于校验是必须的，有没有一种机制能够只保存密码的部分信息，也能用于密码校验？这样即使数据库泄露，攻击者也无法通过这些信息反推用户的密码，进而保护用户账号安全。

哈希函数（hash function）可以解决这个问题。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5KVtuech-1615542644083)(https://content.markdowner.net/pub/3e6Wnp-038oQV9)]

哈希函数是单向不可逆的，从上图很好理解，经过 hash 函数都会被丢弃一部分信息，就如同这个算法：

算法：存储用户名时丢弃用户姓氏然后随机打乱顺序，输入赵日天，输出天日。

即使知道这个算法和天日这个数据，也无法推断出赵日天这个名字，因为部分信息丢失了。

$$h=hash(p)$$