这是一个创建于 2064 天前的主题，其中的信息可能已经有所发展或是发生改变。
AES 加密，看到 CBC 模式，IV 不能重复，IV 不可预测
C/S 构架中，
1、那我是不是要把 IV 和密文一起传输给 Server ？这样就是明文传输 IV ？
2、之后想解密的话，我就要把 IV 和密文都存储起来？
3、AES CBC 用来加密存储用户密码是否合适。
3、AES CBC 256bits 用来加密发送的消息或命令是否合适。
C/S 构架中，
1、那我是不是要把 IV 和密文一起传输给 Server ？这样就是明文传输 IV ？
2、之后想解密的话，我就要把 IV 和密文都存储起来？
3、AES CBC 用来加密存储用户密码是否合适。
3、AES CBC 256bits 用来加密发送的消息或命令是否合适。
 |
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 服务端不能解密吧，不是要服务端能解密？
|
Select Language