关于前后端密码传输与存储？

[daguaochengtang]

登录时，前端调用接口传的密码参数（加密，不加密），以及后端存储密码（加密，不加密）。你们是怎么做的？
排列组合有 4 种：
1. 前端加密，后端加密
2. 前端加密，后端不加密
3. 前端不加密，后端加密
4. 前端不加密，后端不加密
我们目前采用的是第 1 种，用户传输加密后的密码直接和库里加密后的密码比对。但是我偶然听闻了之前 csdn 发生过用户密码大量泄漏的事件。就想到其实前后端都加密的话，如果数据库密码泄露，不就能直接调接口了吗？
所以我想，是不是第 3 种要安全一点，前端传输名文，服务端拿到名文密码后，加密后与库里密码比对。这样即使数据库密码泄露，也无法得知密码名文，就无法调接口了。
当然，我知道，如果数据库都泄露了，光凭这一点已经无法谈及安全问题了。只是想就事论事，想知道你们是怎么做的，这个是否有业内约定俗成的标准？

[3dwelcome]

"只是想就事论事，想知道你们是怎么做的，这个是否有业内约定俗成的标准？"

后端数据加密不是约定，而是强制性的。否则你网站的公安备案，都没办法正常通过。

[bfdh]

如果没有 TLS 的话，可以考虑 challenge handshake authentication protocol 。

[bfdh]

@3dwelcome 强制？那 CSDN 咋回事？

[3dwelcome]

@bfdh CSDN 都多少年前的事情了，那时候还没有公安备案这个说法。

[xingyue]

1 的方案按理说最好呀，不存在楼主说的问题，前端 hash(username+pwd)，后端拿到后 hash(hashPwd+salt)进行存储，即便你数据库泄露了也没法得到 hashPwd，后端鉴权发 token 的接口接收的参数是 hashPwd，别人也没法调用你的接口。ps：ssl 固然安全可信，但是用户环境不可信，避免明文传输还是有必要。

[seesky]

用 1， 不仅客户端不可信， 你同事也不可信， 前端加密防止后端会因为打日志出现泄露风险。

[0bit]

@seesky 是的，据说 twitter 以前就出现过 log 密码明文的情况，还是把密码明文在前端做 Hash 之后再给后端更稳妥

[walpurgis]

hash 不是加密

[killerv]

@marcomarco 加密方式泄漏也无所谓吧，非对称加密，前端使用公钥加密，后端使用私钥解密，没什么问题的。

[killerv]

一般如果不是对安全要求特别高的场景，在 https 的基础上可以选择 3 。另外后端的密码不是加密，是 Hash，不可逆。

[Felldeadbird]

前端用最快，最容易，最简单的 hash 处理原始密码即可。
后面有 SSL，后端二次加密，加盐，加料手段。安全已经完全足够了。

[ZeawinL]

前端使用用户密码为 key 做加密或者 hash，后端对内容进行二次 hash 。

[creanme]

b 站好像是前端从接口获取一个限时的公钥，然后用公钥加密，传到后端，后端用私钥解密？

[TomatoYuyuko]

前端能加个毛线的密，有心破解的话很简单，你正常加盐混淆就行了不用太复杂

[ZeroDu]

其实后端不一定要拿到原始密码。前端 hash 一次，后端再操作一下，直接入库

[FallenTy]

登陆：前端 AES 加密，后端解密 MD5 后，与数据库中的 MD5 比对
注册：明文传输，后端 MD5 存入数据库

[SelFree]

Hash(password) : h1 ------------> Save(Hash(h1 + salt), salt)

[xiangyuecn]

服务器端各种中间件、各种日志、各种分布式集群

抱歉，不出意外很多都是 http 调用🐶 还不带脱敏的，惊喜不惊喜，前端对密码进行加密、hash 的重要性就比较突出了

另外前端不传明文，对不是特意针对你网站的中间人有一定的防御力，至少不会输一下密码，人家随随便便就能知道这是明文密码

不推荐 hash，应该用对称加密或非对称加密，并且密钥是变化的，如果不变就和 hash 没什么两样

[zhaokun]

1，前端简单 hash，后端再加密后存储

[zhaokun]

当然也有 https （ https 也不可信，大多数是可以破解的）