你的账号安全嘛？

前一段时间闹得沸沸扬扬的主打安全的“红芯浏览器”最后证明并不安全。华住酒店上亿条开房信息泄露。互联网时代虽然很难有个人隐私，但大家还是希望自己的在各大门户网站或App中的电子账号能够尽量安全。如何来保证我们的这些信息的安全呢，今天来简单的分享安全技术中的一个领域：密码学中的加密算法。希望大家看完今天的文章后能好好的审查一遍自己在各个平台的账号密码是否足够安全。

加密算法的分类：

哈希算法（Hash）,应用中通常称为指纹（fingerprint）或者摘要（digest）。

要求算法对于任意长度的输入内容，输出定长的Hash值结果。数据是不可逆的，即根据Hash值是无法反推出原文内容的。（因为不可逆这一点很多观点认为Hash算法不属于加密算法，此处我们不对其进行进一步的讨论）。

代表算法：MD5、SHA等

对称加密：加解密的密钥相同。举个例子：一把钥匙（密钥）既能锁门（加密）也能开门（解密）。

对称加密的计算效率高，广泛应用到生产领域，但其有个致命的缺陷就是需要提前共享密钥，这就可能导致密钥的泄露，进而导致数据的不安全。

代表算法：DES，AES等。

非对称加密：加解密的密钥不同。举个例子：锁门（加密）和 开门（解密）用两把钥匙（公钥，私钥），用公钥锁的门需要私钥来开，用私钥锁的门需要公钥来开。

非对称加密是当代密码学历史上一项伟大的发明，能够很好的解决对称加密中提前共享密钥的问题，目前主要基于大数质因子分解、离散对数、椭圆曲线等经典数学难题进行保护。

代表算法：RSA、ECC、SM2等。

看到这也许有的朋友可能存在疑问，前面解释的加密算法都是公开的加密算法，如果我自己设计一个加密算法然后不对外公开，别人不知道我怎么加密的数据不就可以保证我的数据安全了吗？对这个问题我只能说可以应付一定的小范围场景，但是一旦你的应用达到一个量级，你所面对的黑客对这些非公开算法破解速度那是分分钟的事情。实际上，密码学实现的安全往往是通过算法所依赖的数学问题来提供，而并不是通过对算法的实现过程进行保密。

理论铺垫基本结束，下面结合一个常用的应用场景展开：

账号登陆，这个所用互联网用户应该都不陌生，当我们输入账号密码后点击确认后，我们的这些基本数据经历了什么样的过程呢？

场景1

入门的登陆逻辑，自然风险很多。列举两个致命的：

风险1：账号密码数据直接未处理就往服务器发，被黑客直接截获数据。

风险2：服务器中存储了用户的账号密码，数据库一旦被黑客攻破就会到账用户的密码信息泄露。

场景2

升级一下，数据采用了对称加密，密码也采用的Hash处理，一下子安全了许多。但是还有不少问题，随便说两个问题：

风险1：密钥在公网传输，黑客截获了密钥就可以破解数据，虽然说黑客并不知道用户的真正密码，但是有了这个密码的Hash后就正常的登陆当前这个网站/App 甚至 其他同密码的平台。

密码如果只简单的采用Hash处理是不够的，简单的密码是可以撞出来的（http://www.cmd5.com这个网站就可以直接通过md5列出原始数据）。平台无法避免用户用一些简单的密码，面对这个问题如何来保证用户数据的安全呢？通常会对数据会进行加盐（salt）操作，所以用户还是尽量用复杂的密码。

风险2：数据无签名，加密数据被篡改后无法验证，黑客即使在没有密钥的情况下也可以篡改数据欺骗服务器。

场景3

再升级一下，现在采用了非对称加密，密码也加了盐，黑客窃取了公钥也无法破解客户端发到服务器的数据，数据加了签名，一旦黑客篡改了用户的网络数据，服务器也会检测到。这回貌似能够商用了。

别高兴的太早，这个还有不少问题：

风险1：黑客无法破解数据也不能篡改数据，但是依旧无法影响黑客截取数据包并模拟你的账号的登陆。

风险2：非对称加密由于其性能问题，目前只是用来交换核心数据时才会使用，平时大部分的数据交换还是对称加密的方式，对称加密的密钥是用非对称加密来传输的。

风险3：盐是不会写死在客户端的，这个也需要服务器来下发，另外盐泄露了又怎么办？ 如何来保证其有限时效性。

场景4

好了，针对之前的版本再进行升级，对每个账号服务器生成一个随机的KEY用非对称加密处理后传输给客户端。数据加入服务器时间戳（TICK）来作为登陆的验证，来屏蔽黑客的模拟登陆。HMAC是密钥相关的哈希运算消息认证码，HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。salt 和 key都由服务器下发给客户端。但是现在就没有问题了吗？

未完待续~~？