最近有朋友在使劲研究如何不使用 HTTPS 的情况下保护用户密码安全。暂且不说研究过程,但结论是要保障安全必须后端参与,使用非对称加密算法 —— 如此一来,不如直接用 HTTPS 更简单便捷有保障。使用免费 SSL 证书,一年一换,运维稍微麻烦一点,访问稍微慢一点(证书认证过程好像会慢一些),但至少是专业的,比自己研究的没经过大量检验的算法靠谱多了。
假设已经做过必要的安全防范,目前唯一需要解决的问题是保障用户密码在 HTTP 的明文传输过程中不被窃取。为达此目的,研究过程如下:
对称算法加密密码
如果说,密码在明文传输过程中存在风险,最直接的解决办法是让密码不再是原来的样子。使用一个 KEY
来加密密码,再将加密后的结果传输到后台,由后台解密使用。
看起来确实起作用,如果窃取到加密后的密码数据,没有 KEY
是不能解密出来的。然而,KEY
要用于前端加密,就一定会存在于前端的某个地方,而前端的所有资源都是用户可以获取并分析的,甚至可以使用浏览器的开发者工具通过各种调试手段来分析获取。所以 KEY
本身并不能安全保存,安全性被打破。
此外,如果 secure_data
在传输过程被窃取,是可以重复使用的(因为 KEY
不变,加密结果就不会变),这也是一个不安全因素。
结论 📚使用对称加密算法来加密密码的方式不能保证密钥安全,也不能保证用户密码安全,更不能保护注册/登录过程安全。
对密码进行单纯的 HASH
使用对称加密,在密文和密钥都被窃取的时候,可以解出密码原文,对用户在其他系统中(可能使用了相同密码)造成威胁。为此,我们可以使用不可逆的 HASH 算法来处理密码,只要前后端计算方式相同,不需要解密出密码原文,直接使用 HASH 结果就行。
用户注册时,假设我们有原密码 my_password
,使用 MD5 计算后是 a865a7e0ddbf35fa6f6a232e0893bea4
。这个 HASH 送到后端之后,后端是不能从 HASH 反算出原密码的,所以后端只能直接保存这个 HASH。
那么验证的时候,同样将原密码计算成 HASH a865a7e0ddbf35fa6f6a232e0893bea4
,传输到后端,后端拿它和保存的数据进行对比,相同则验证通过。
有问题吗?当然有,你看 ——
使用 Hash 的过程
不使用 HASH 的过程
从传输过程开始,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
,来看看下面这个登录过程:
攻击者只需要窃取 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_key
和 hmac_result
两部分。他们都能被窃取使用。这种状态下如果要保证 secure_key
只能使用一次,就必须要后端缓存所有用过的 secure_key
备查 —— 显然这会极大的增加后端负担。因此,不可以由前端来产生动态安全码。
用后端产生动态安全码之后可以立即缓存起来,同时传输给前端(这个过程可以前端发起请求)。前端按上述步骤对用户密码进行加密,将数据送回后端。后端检查 secure_key
在缓存中,取出来计算用于验证的 hmac_result
,同时从缓存中删除 secure_key
;如果 secure_key
不在缓存中,直接拒绝验证。
引入动态 secure_key
解决了登录期间验证用户密码的问题。
虽然数据在传输过程中仍然能被窃取,但是被窃取的数据不能重复使用,也不易破解出密码原文(可花长时间暴力破解),所以这个方案是初步可行的 —— 但要注意,它可能会受中到中间人攻击。
此外,该方案是不完整的,因为它只能解决验证密码(登录)的问题,不能解决保存密码(注册)的问题 —— 注意到后端是直接从数据库加载的 my_password
,这意味着在注册时需要传入密码原文或者可解密出密码原文的密文 —— 这在之前的研究中都还没找到办法。
结论 📚后端产生一次性使用的动态
secure_key
可以保障登录安全,但不能解决注册安全。而且该方案需要注意防护中间人攻击。注意:需要后端参与
使用非对称加密
到目前为止,我们总算找到一个前端登录勉强可用的安全方案。接下来还要研究用户注册时该怎么办。
注册时需要传输可解密的密文,而且在前端不能找到可用于解密的密钥 —— 这个场景非常符合非对称加密的应用场景 —— 前端使用公钥加密,后端使用私钥解密,问题就能得到完美解决:
结论 📚使用非对称加密算法,可以保护用户密码安全,也可以保护登录过程安全。但是要注意中间人攻击。
注意:需要后端参与
使用 HTTPS
到此为止,我们已经非常接近 HTTPS 了。HTTPS 主要就是采用的非对称加密算法来保证数据传输安全。为了防止中间人攻击还引入了公信机构(受信任的证书中心)。但是,这个安全过程的参与方,包括 HTTPS 使用的安全协议(SSL 和 TSL 等)、服务器、公信机构、用户自己等,都可能成为整个安全过程的短板。
作为专业保障 HTTP 传输安全的 HTTPS 协议都随时在曝漏洞,请问,你又哪里来的信心凭一已之力用自己的安全算法实现来代替 HTTPS?如果没有足够的能力,还是安心用 HTTPS 吧!
请关注公众号边城客栈⇗
看完了先别走,点个赞 ⇓ 啊,赞赏 ⇘ 就更好啦!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。