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

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万用户密码泄露始末：暂关闭登录

为什么不能明文存储密码

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

为什么这样做是不安全的/p>

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

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

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

来自知乎用户：Right Here

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

如何存储 & 检查密码

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

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

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

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

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

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

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

h = h a s h ( p ) h = hash(p) h=hash(p)

h 为最终存储到数据库的值，p 为用户原始密码，在用户登陆时，输入密码 p1，我们通过计算 h 1 = h a s h ( p 1 ) h_1 = hash(p_1) h1/span>=hash(p1/span>)，判断 h1 是否与数据库中的记录 h 相同，确定用户输入的密码是否正确。

所有哈希函数都有一个性质：如果两个 h 值是不一致的，那么输入 p 值也不一样（单向散列函数），但另一方面输入和输出并非一一对应的关系，比如存在不同的 h 值，使得经过 hash 函数计算后的 p 值是一样的。

哈希函数就安全了吗/h2>

没有，由于上述哈希函数的性质，如果两个用户都用了123456abc，这样的密码，那么数据库存储的 h 值都是一样的，而且不同密码可能计算出来的 h 值是一样的（碰撞攻击），那么攻击者就可以根据 hash 函数，暴力计算所有可能性，做成一张表格，这样拿到 h 值的时候就可以推断出密码是 123456abc 了。这种做法叫彩虹表攻击。

用户在客户端软件上产生数据（比如浏览器上），经过 https 加密传输到后端服务器，有服务端软件处理（比如 java），之后经过调用数据库接口通过数据库软件（比如 mysql）存储到存储设备中（比如硬盘）。

有 4 个阶段可以进行数据加密，加密的过程越靠近用户越安全（客户端加密后面说）：

• 服务端软件加密：数据到达服务端后立马加密存储（内存中执行），比如 java 执行 AES256
• 数据库软件加密：调用数据库API实现数据库加密，比如 mysql 的 AES 加密
• 存储端落盘加密：使用硬件加密技术进行加密存储，比如云服务商提供的云盘加密功能

前两者加密方式都可以保证即使是数据库管理员也无法查看用户数据，最后一种通常意义不大，但一些国家、地区的法律要求，或者用户要求有硬盘加密措施，仍然需要使用。数据库软件加密仍然存在内部泄露的风险，比如 mysql 的 binlog，即使你使用了 AES256，数据同步时密钥也会存储在 binlog 中，存在泄露的途径。

如果相关用户数据没有搜索的需求（只有常规读写需求），可以使用服务端加密或者数据库加密的手段保护用户数据。但如果相关数据需要支持搜索功能，这个问题就很棘手了。

可搜索加密技术

前面没有提到的客户端加密放这里说。加密点越靠近用户，就越安全，如果用户发出来的数据就是经过加密的（非 https 类传输加密），并且自行控制密码，这样服务提供商也无需进一步做加密处理了，标题提到的不用加密指的就是这个，服务商不用再花费大量精力、成本在数据安全上面，将数据所有权交给用户。

上面客户端加密所需的一个技术就是：全同态加密，这是密码学领域的一个重要课题，在 2009 年 9 月，IBM 的博士克雷格·金特里发表了一篇论文：Fully Homomorphic Encryption Using Ideal Lattices，提出了一个可行方法，自此解决了密码学的一大难题。全同态加密可以简单理解如下：

f ( d a t a ) = D E (   f (   E ( d a t a )   ) ) f(data) = DE( f( E(data) )) f(data)=DE( f( E(data) ))

其中 f 是任意操作函数，E 是加密函数，DE 是解密函数，也就是说对密文的任意计算操作等同于对明文做同样的操作。

这就很牛逼了！！！！！！！！！！！比如我手上有一些财务数据，需要第三方机构进行统计分析，但是我又不想直接给他们数据，他们告诉我可以提供全同态加密服务，那么我可以在给他们数据之前将数据加密一遍，他们给我统计计算后的结果，我解密相关结果即可，真实的数据只有我看得到。

全同态加密的这些特性能够很好解决数据安全，信任的问题，克雷格·金特里给出了一个实现，之后很多密码学者也给出其他实现方法，但目前的角度来说该技术还不成熟，比如一个密钥就得 100 MB 大小，对于当下 络环境来说无法实际使用。

结语

没有绝对的安全，只有相对的安全。期待全同态加密技术在商用领域取得突破性进展。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91725 人正在系统学习中