HTTPS 用明文传输密码的问题的引申——前端能不能做到比较完美的加密

[Torpedo]

最近密码用不用明文传到后端的问题很火。前端不加密的很重要一个点是加密太容易暴露。因为 js 可以被用户比较轻易的看到，造成加密算法的泄露。

不过开发过程中，还是有些加密需求的。比如防爬虫之类的。像客户端一般都是携带参数算出的 token 。而前端因为上述原因，很少采用类似的方案

其实客户端也不是没法破解，只不过成本比较高。web 上我见过的接口，谷歌地图的接口也是加密过的。

大家实践里有什么破译成本比较高的方案呢？

[CloudMx]

不管怎样，密码这种信息都不建议使用加密方法，而是使用 HASH 摘要算法进行处理后进行传输、存储。
它不需要“解密”还原成密码明文。

[dzdh]

wasm

[cmdOptionKana]

安全、防爬，这是个无底洞，基本上就是八仙过海各显神通，攻防两端互相斗法，这是一场无休止的战争，没有一劳永逸的方法。

[adnoh]

要看防谁，客户端还是传输层

[wy315700]

任何加密系统都绕不开信任预置的问题。双方有一个共同信任的东西。。

SSL 里的话这个东西就是根证书。



----因为 js 可以被用户比较轻易的看到，造成加密算法的泄露。----

一个成熟的加密系统不应该依赖算法的保密，而是通过密钥管理来达到安全性的目的。



如果是为了防止中间人抓包的话，Static SSL Pinning 就行了

[povsister]

#3 概括的很清楚了，没有一劳永逸的方式。
尤其是 Web 这种你前端代码都跑在用户端的情况下，更不可能有无懈可击的方案。

更多时候是看你需要加强什么防护，从而针对性的采取一些措施：代码混淆，验签，wbi ，SSL pinning 都是侧重不同方面

[skyqiao]

密码不需要解密吧

[busier]

前端加密要安全也不是不可能，既然前端算法和密钥都藏不住，那么在前端实现与 SSL 一样的 RSA 非对称加密即可。

至于在前端 HASH 后在传输，恕我直言就是脱了裤子放屁。

[busier]

补充，当然可以考虑在前端代码中实现 PGP ，这样要容易些。

[CloudMx]

使用 RSA 也需要防止中间人，这些都是相辅相成的安全策略，应对不同的攻击方式。
我不同意 HASH 后传输是脱裤子放屁，因为密码这种敏感信息数据库是没必要存储明文信息或者加密后的信息的，只需要 HASH 后，存储，不管你从什么业务考虑。HASH 摘要算法你到后面的攻击方式想要对应的明文，无非就是去查字典或者自己生成字典跑。

[flyqie]

@CloudMx #10

现在很少有厂商存明文了吧。

hash 后传输算是为了防止在整个链路中看到原始密码。

安全性上确实也是有些用的，起码看不到明文了，不算脱裤子放屁但很多时候意义不是特别大。

[ck65]

Web E2EE 可以参考一下 matrix 的操作

- https://matrix.org/docs/matrix-concepts/end-to-end-encryption/
- https://webrtchacks.com/how-does-webrtc-end-to-end-encryption-work-matrix-org-example-dave-baker/

[BeautifulSoap]

@CloudMx 4202 年了，哪个厂商后端还会直接把拿到的原始密码直接入库，学后端开发自己手撸用户模块的话所有教程第一节课都会教你服务端要把密码 hash 后存储。用的如果是正经的现代框架的话，我反正没见过现在什么主流框架的用户模块会直接往 db 里存未处理的密码原文的（如果真有的话建议说出来让大家开开眼，估计这框架将会成为开源界的耻辱了）

[pkoukk]

3 楼说的没错，看你要防谁。
你是要防泄露，还是防滥用，还是防第三方客户端
按你要防的具体的东西，再去选择适合的方案，虚头巴脑的讨论浪费口水

[CloudMx]

@flyqie 就是密码这种东西，根本不需要传输明文到后端，不管你业务怎么使用，比如：验证密码，历史密码记录等。不可直接"逆向"成对应明文它最大的意义就是这。

[CloudMx]

@BeautifulSoap 有啊，我想说的不是明文，而是任何加密形式的密码保存都不应该存在，密码对应的只能存储对应 HASH 。你非对称也好、对称也好，都可以解密。HASH 这种，稍微加点盐，你就只能自己跑字典。

[CloudMx]

任何密码信息，都不应该存储明文、加密存储，而是 HASH 摘要存储。除非你说你要在后端验证密码复杂度。

[BeautifulSoap]

@CloudMx 对于后端来说，前端无论传的是密码原文还是 hash 后的值，在后端看来那都是“明文密码”，这点你能反应过来吗？比如用户密码 123456 ，sha256 一下就是 effff....16c 。那么对后端来说，effff......16c 就是明文密码。我是个攻击者，知道了你这串 effff....16c 直接用这个值请求登录 api 就登录进去了。前端你 hash 不 hash ，结果和明文密码并没任何不同


然后这里还有个问题，你有没有考虑过加盐 hash 到底应该在哪一步才好？
方法 1. 前端传密码原文，后端加盐 hash 入库
方法 2. 前端加盐 hash ，然后直接将结果入库

这里，比起方法 1 ，方法 2 是存在极其严重的安全漏洞的。加盐 hash 保证安全的前提是“盐是保密”这一点，前端加盐=盐被公开，当你盐被公开而后端又直接入库的话等同于用了方法 1 但后端的盐泄露了的情况。
所以前端加盐 hash 为了保证安全，那么你后端必须要再用另外的盐再 hash 一次：
方法 3. 前端加盐 hash ，后端再用另外一个盐 hash 入库
这时候方法 3 本质上和方法 1 并没任何不同（因为对后端来说无论你前端传什么过来对后端来说都是密码原文），只不过从一次 hash 变成了两次 hash 。那么这就又有个问题了，你都搞了两次 hash 了，为什么不为了安全后端多来几次，3 次，4 次，10 次，100 次？所以仅从数据入库角度来看，前端 hash 不能说脱裤子放屁，那也是没用处的

[CloudMx]

你说 HASH 化后的密码可以登录，这个是毋容置疑的，后端接收后就是验证这一串值的，你后端看见的就是你说的“明文密码”，它只要去跟数据库里面的去对比就行，不管你是什么。

但是我这里表达的是，我前端 HASH 后，你后端接收是不可能反推出我的明文的，但是如果你用加密方式，你是有机会的，谁知道你会不解密我的密文干些啥。

你说的在哪一步好，我的建议是方法 2 或者方法 3 ，理由就是上面说的，我不想也不愿意你存储我的明文。

方法 1 跟方法 3 有区别，方法 3 后端永远不可能知道我的明文。

方法 2 跟方法 3 是没有什么区别的，硬要说就是双 SALT ，一个前端 SALT ，一个后端 SALT+前端 SQLT 。对于攻击者来说，要么中间人的时候获取到出来后的 HASH ，直接跑字典，要么获取到数据库查询权限后，获取到对应的 HASH 值以及后端的盐，前端的盐默认就是公开的(这里不考虑中间人直接插 JS)。

[CloudMx]

@BeautifulSoap