离开后端说前端加密都是空谈

最近有朋友在使劲研究如何不使用 HTTPS 的情况下保护用户密码安全。暂且不说研究过程,但结论是要保障安全必须后端参与,使用非对称加密算法 —— 如此一来,不如直接用 HTTPS 更简单便捷有保障。使用免费 SSL 证书,一年一换,运维稍微麻烦一点,访问稍微慢一点(证书认证过程好像会慢一些),但至少是专业的,比自己研究的没经过大量检验的算法靠谱多了。

假设已经做过必要的安全防范,目前唯一需要解决的问题是保障用户密码在 HTTP 的明文传输过程中不被窃取。为达此目的,研究过程如下:

对称算法加密密码

如果说,密码在明文传输过程中存在风险,最直接的解决办法是让密码不再是原来的样子。使用一个 KEY 来加密密码,再将加密后的结果传输到后台,由后台解密使用。

image.png

看起来确实起作用,如果窃取到加密后的密码数据,没有 KEY 是不能解密出来的。然而KEY 要用于前端加密,就一定会存在于前端的某个地方,而前端的所有资源都是用户可以获取并分析的,甚至可以使用浏览器的开发者工具通过各种调试手段来分析获取。所以 KEY 本身并不能安全保存,安全性被打破。

此外,如果 secure_data 在传输过程被窃取,是可以重复使用的(因为 KEY 不变,加密结果就不会变),这也是一个不安全因素。


结论 📚

使用对称加密算法来加密密码的方式不能保证密钥安全,也不能保证用户密码安全,更不能保护注册/登录过程安全。

对密码进行单纯的 HASH

使用对称加密,在密文和密钥都被窃取的时候,可以解出密码原文,对用户在其他系统中(可能使用了相同密码)造成威胁。为此,我们可以使用不可逆的 HASH 算法来处理密码,只要前后端计算方式相同,不需要解密出密码原文,直接使用 HASH 结果就行。

用户注册时,假设我们有原密码 my_password,使用 MD5 计算后是 a865a7e0ddbf35fa6f6a232e0893bea4。这个 HASH 送到后端之后,后端是不能从 HASH 反算出原密码的,所以后端只能直接保存这个 HASH。

那么验证的时候,同样将原密码计算成 HASH a865a7e0ddbf35fa6f6a232e0893bea4,传输到后端,后端拿它和保存的数据进行对比,相同则验证通过。

有问题吗?当然有,你看 ——

使用 Hash 的过程

image.png

不使用 HASH 的过程

image.png

从传输过程开始,Hash 前的过程和 Hash 后的过程并没有区别。对于偷窃者来说,无所谓是拿到的 my_password 还是 a865a7...,只要把它送到后端,就能成功登录。

所以这种做法并不能保护用户登录!

不过密码是采用 Hash 计算过的,是不是能保护用户密码不会窃取用于尝试登录其他系统呢?也不能!

一些常见的密码,比如 123456 采用 MD5 计算后是 e10adc3949ba59abbe56e057f20f883e,拿这个 Hash 上百度就能查出来原密码是 123456。当然,专业人士会有专业的工具,也就是彩虹表(什么是彩虹表?查查呗!),数以 TB 计的数据,可能大部分密码都查得出来吧。


结论 📚

从前端对密码进行单纯的 HASH 算法,起不到任何保护作用。

其实从后端对密码进行单纯的 HASH 加密也只能起到很弱的保护作用,几近裸奔。

引入密钥,使用 HMAC

HMAC 比单纯的 HASH 算法,要多一个密钥因素,可以认为是加密的 HASH。使用 HMAC 可以有效的阻碍彩虹表破解。因此使用 HMAC 保护用户密码原文。但是,如果传输的是 HMAC 计算结果,和前面的讨论同理,并不能保护登录。

但使用 HMAC 和单纯的 HASH 又有那么一点不同。假设我们已经通过其他方式进行安全的注册,后端已经保存了用户密码 my_password,来看看下面这个登录过程:

image.png

攻击者只需要窃取 hash_result 即可仿冒登录,而 hmac_result 在传输过程中可以轻松窃取。

此外,还有一个不安全点:固化在脚本中的 secure_key 是可以从拉到客户的脚本资源中分析出来的。


结论 📚

使用固定 secure key 的 HMAC 算法并不能保障登录安全,只能起到保密用户密码原文的作用。但是,由于 secure_key 很容易被拿到,所以对密码原文的保护也相对较弱。

引入动态安全码 (secure key)

继续寻找解决办法,我们可以想到一个改进方案:如果满足下面两个条件,上面遇到的问题似乎就能解决:

  • secure_key 并不是固定在脚本中,而是动态产生的,就可以解决从脚本分析获得 secure_key 的问题;
  • 这个 secure_key 使用 1 次后立即失效,那么 hmac_result 就不能用于再一次登录,可以解决 hmac_result 被窃取复用的问题。

动态 secure_key 看起来是个不错的办法,但是它应该在哪里动态产生呢?

如果在前端动态产生,就必须通知后端,传输的数据需要包含 secure_keyhmac_result 两部分。他们都能被窃取使用。这种状态下如果要保证 secure_key 只能使用一次,就必须要后端缓存所有用过的 secure_key 备查 —— 显然这会极大的增加后端负担。因此,不可以由前端来产生动态安全码。

image.png

用后端产生动态安全码之后可以立即缓存起来,同时传输给前端(这个过程可以前端发起请求)。前端按上述步骤对用户密码进行加密,将数据送回后端。后端检查 secure_key 在缓存中,取出来计算用于验证的 hmac_result,同时从缓存中删除 secure_key;如果 secure_key 不在缓存中,直接拒绝验证。

image.png

引入动态 secure_key 解决了登录期间验证用户密码的问题。

虽然数据在传输过程中仍然能被窃取,但是被窃取的数据不能重复使用,也不易破解出密码原文(可花长时间暴力破解),所以这个方案是初步可行的 —— 但要注意,它可能会受中到中间人攻击。

此外,该方案是不完整的,因为它只能解决验证密码(登录)的问题,不能解决保存密码(注册)的问题 —— 注意到后端是直接从数据库加载的 my_password,这意味着在注册时需要传入密码原文或者可解密出密码原文的密文 —— 这在之前的研究中都还没找到办法。


结论 📚

后端产生一次性使用的动态 secure_key 可以保障登录安全,但不能解决注册安全。而且该方案需要注意防护中间人攻击

注意:需要后端参与

使用非对称加密

到目前为止,我们总算找到一个前端登录勉强可用的安全方案。接下来还要研究用户注册时该怎么办。

注册时需要传输可解密的密文,而且在前端不能找到可用于解密的密钥 —— 这个场景非常符合非对称加密的应用场景 —— 前端使用公钥加密,后端使用私钥解密,问题就能得到完美解决:

image.png


结论 📚

使用非对称加密算法,可以保护用户密码安全,也可以保护登录过程安全。但是要注意中间人攻击

注意:需要后端参与

使用 HTTPS

到此为止,我们已经非常接近 HTTPS 了。HTTPS 主要就是采用的非对称加密算法来保证数据传输安全。为了防止中间人攻击还引入了公信机构(受信任的证书中心)。但是,这个安全过程的参与方,包括 HTTPS 使用的安全协议(SSL 和 TSL 等)、服务器、公信机构、用户自己等,都可能成为整个安全过程的短板。

作为专业保障 HTTP 传输安全的 HTTPS 协议都随时在曝漏洞,请问,你又哪里来的信心凭一已之力用自己的安全算法实现来代替 HTTPS?如果没有足够的能力,还是安心用 HTTPS 吧!


边城客栈

请关注公众号边城客栈

看完了先别走,点个赞 ⇓ 啊,赞赏 ⇘ 就更好啦!

阅读 4.1k

推荐阅读
边城客栈
用户专栏

全栈技术专栏

3148 人关注
77 篇文章
专栏主页