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

我们一般是 3，然后传输过程加密，让人拦截不到传输内容。

@marcomarco 前端也加密的话，那如果是网页端岂不是加密方式都直接泄露了？

前端加密的意义何在？

密码不应当存储为明文或可逆加密的密文。

前端不加密，走 https，后端也不加密，只保存 hash

前后端加密肯定不是一套加密方案...不管前加不加后端肯定得独立一套方案

通常是第 3 种，前端不加密走 HTTPS，后端增添加密因子进行特定算法法加密

前端可逆加密，后端不可逆加密。

如果传输协议是 https / tls 保护的，前端可以不加密。

@feikeq 明白了

跟楼上一样，前端不加密，但是走 https，后台拿到原始密码后给每个用户生成一个独立的盐（ salt ），然后再把原始密码和盐一起做 hash，hash 结果存到数据库。 验证的时候，做同样的 hash 运算，跟数据库里面的 hash 结果比对。

这样的好处是即使数据库泄露，也不会暴露用户的原始密码。

学习学习

不用 argon2 的都是耍流氓

直接 Spring Security 一套用上,加密方式选择 Bcrpt

用 BCrypt 啊
Java

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
new BCryptPasswordEncoder().encode(password);
new BCryptPasswordEncoder().matches(rawPassword, encodedPassword);

PHP
echo password_hash(‘123456’, PASSWORD_DEFAULT); // 获取密码
var_dump(password_verify(‘123456’, '$2a$10$QoH8aP4NjR.h6IJwQ4S9l.8xbryqH28UtaorHeF3uBk7h72O4J4lu')); // 校验密码

有 TLS 前端不加密也行.

前端 AES 加密
后端 AES 解密后再 MD5()
数据库 MD5 存储
再加 HTTPS

前端加密就是在搞自己

安全的储存密码是为了不泄露用户明文密码，防止用户使用相同密码的其他服务被社工攻击。而不是为了防止调用你的接口，你密码表都被拖了，你还谈啥接口安全，直接拿你表里的 token 登入就行了。
不过一和三都能防止你所提到的问题

前端页面直接将密码加密后，传到后端，后端拿着用户名与密码去数据库匹配。

这样被社工的几率小。首先密码长度是固定的，先判断密码长度，可以过滤一部分社工。另外，密码加密传输，相对明文存储要安全很多。

https 加上专门设计保存密码的 hash 算法 (Argon2id/scrypt/bcrypt/PBKDF2) 就行了。

https://github.com/P-H-C/phc-winner-argon2
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
https://datatracker.ietf.org/doc/html/draft-ietf-kitten-password-storage-06

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

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

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

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

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

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

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

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

hash 不是加密

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当然选 2 了，前端加密骗用户，后端明文卖密码。

@zhaokun 破解 HTTPS? 愿闻其详

3. 前端不加密，后端加密

frontend:
POST https://domain/login --data "username=admin" --data "password=12345"

backend:
sql = select * from `user` where `username` = :username
result = db.get(sql, {:username => POST.username})

if (result) {
if ( password_verify(POST.password, result.password_bcrypt_hashed) ) {
// login success
} else {
// login fail
}
} else {
// user not found
}

前端加密毫无意义，加密的算法必须由后端把控。客户端的所有信息都是不安全的。

加密后的密码 加盐 再保存到数据库

加盐 加盐 加盐

前端加密倒也不是完全脱裤子放屁，现在有 wasm 了反编译成本还是挺高的

25 楼说的对。
主要是过智障安全测评不能传明文密码这一关

前端加密没用的 再复杂的加密，也只是增加逆向的难度而已。只有时间够长 总能找到加密的入口函数

前端加密没用的 再复杂的加密，也只是增加逆向的难度而已。只要时间够长 总能找到加密的入口函数

1，前端哈希不是防小人，是防手滑。后端必须上安全的哈希算法