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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1226 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

加密

密码

名文

前端

51 条回复 • 2021-07-15 04:19:59 +08:00

marcomarco

2021-07-14 08:53:49 +08:00 via iPhone

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

marcomarco

2021-07-14 08:55:29 +08:00 via iPhone

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

sutra

2021-07-14 08:57:54 +08:00

前端加密的意义何在？

mingl0280

2021-07-14 09:00:19 +08:00 via Android

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

cmdOptionKana

2021-07-14 09:00:43 +08:00

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

Tardis233

2021-07-14 09:01:26 +08:00

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

feikeq

2021-07-14 09:03:17 +08:00

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

InDom

2021-07-14 09:09:48 +08:00

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

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

daguaochengtang

2021-07-14 09:10:09 +08:00

@feikeq 明白了

wangxiaoaer

2021-07-14 09:11:17 +08:00

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

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

dxatgp02

2021-07-14 09:11:48 +08:00

学习学习

dzdh

2021-07-14 09:16:16 +08:00

不用 argon2 的都是耍流氓

soulzz

2021-07-14 09:20:12 +08:00

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

CodeCodeStudy

2021-07-14 09:27:02 +08:00

用 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')); // 校验密码

2kCS5c0b0ITXE5k2

2021-07-14 09:30:13 +08:00

有 TLS 前端不加密也行.

z960112559

2021-07-14 09:32:25 +08:00

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

securityCoding

2021-07-14 09:34:37 +08:00

前端加密就是在搞自己

xmumiffy

2021-07-14 09:44:04 +08:00 via Android

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

abccccabc

2021-07-14 09:48:30 +08:00

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

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

expy

2021-07-14 09:51:46 +08:00

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

3dwelcome

2021-07-14 09:59:32 +08:00

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

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

bfdh

2021-07-14 10:08:49 +08:00

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

bfdh

2021-07-14 10:09:50 +08:00

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

3dwelcome

2021-07-14 10:10:47 +08:00

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

xingyue

2021-07-14 10:11:27 +08:00 via Android

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

seesky

2021-07-14 10:18:03 +08:00

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

0bit

2021-07-14 10:58:50 +08:00

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

walpurgis

2021-07-14 12:15:28 +08:00 via iPhone

hash 不是加密

killerv

2021-07-14 13:20:32 +08:00

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

killerv

2021-07-14 13:21:13 +08:00

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

Felldeadbird

2021-07-14 13:25:28 +08:00

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

ZeawinL

2021-07-14 13:31:05 +08:00 via Android

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

creanme

2021-07-14 13:43:05 +08:00 via Android

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

TomatoYuyuko

2021-07-14 13:55:22 +08:00

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

ZeroDu

2021-07-14 14:21:28 +08:00

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

FallenTy

2021-07-14 15:44:26 +08:00

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

SelFree

2021-07-14 16:11:35 +08:00

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

xiangyuecn

2021-07-14 16:15:46 +08:00

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

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

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

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

zhaokun

2021-07-14 16:31:37 +08:00

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

zhaokun

2021-07-14 16:32:07 +08:00

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

Kaciras

2021-07-14 16:54:56 +08:00

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

CrazyRundong

2021-07-14 17:58:09 +08:00 via iPhone

@zhaokun 破解 HTTPS? 愿闻其详

hgc81538

2021-07-14 20:30:31 +08:00

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
}