1
cpdyj0 2019-03-22 23:24:46 +08:00
不明白为什么不适用哈希方案呢?
|
3
hoyixi 2019-03-22 23:37:47 +08:00
设计个安全的重置密码方案不行吗,非要解密密码?
|
4
lqs 2019-03-22 23:39:26 +08:00
应该分两个方面来考虑:
1. 客户端如何把密码传送给服务端 2. 服务端如何存储密码 |
5
mason961125 2019-03-22 23:59:29 +08:00
C/S 我觉得还是 公钥 /私钥 模式更好,算法告诉他,公钥给他,随便他弄都解不出来。
|
6
cpdyj0 2019-03-23 00:01:31 +08:00
似乎 IV 必须传递给服务器,只要 key 安全就没啥问题,那么建议服务端密码部分多设计下,和主业务部分隔离开。key 周期性更换,对各种读写做审计。
|
7
cpdyj0 2019-03-23 00:03:09 +08:00
哦,我脑残了,key 不可能不泄露,客户端需要加密。。。
那么建议楼上的非对称方案,同时保留哈希方案,用作一般登录校验,非对称只用来获取密码明文时使用,做审计。 |
8
lovedebug 2019-03-23 00:08:09 +08:00 via Android
aes cbc 刚爆出漏洞没多久吧
|
9
cxtrinityy 2019-03-23 00:09:44 +08:00
如果你的初始 iv、key、salt 什么的明文传输,那么 cbc 也没有意义吧,cbc 是链式的,只是拿前一块密文异或下一块明文后加密,又不是魔法,安全传输还是考虑下 https 比较好
到了服务器了,你是不是 cbc 也无所谓了吧 |
10
Alexinder 2019-03-23 05:14:28 +08:00 via Android
密码存储用 hash 不要用加密
|
11
yzwduck 2019-03-23 06:09:39 +08:00 via Android
3、不合适,绝对不要用可逆加来保存口令,一旦泄漏加密密钥,口令就立马变成明文。
4、不合适,加密传输还需要解决密钥交换等一系列问题,实现过程非常复杂。建议用已有的 TLS/HTTPS + 证书。 @lovedebug 能否请教一下最近 aes cbc 爆出了什么漏洞? |
13
zyxk OP @cxtrinityy #9 IV salt 传输 ,key 肯定不传输的。
|
14
cxtrinityy 2019-03-23 16:50:53 +08:00 via Android
@zyxk 对称加密不传 key 服务端不能解密吧,不是要服务端能解密?
|