AES 加密相关的问题， CBC 用来加密存储用户密码是否合适。

[zyxk]

AES 加密，看到 CBC 模式，IV 不能重复，IV 不可预测
C/S 构架中，
1、那我是不是要把 IV 和密文一起传输给 Server ？这样就是明文传输 IV ？
2、之后想解密的话，我就要把 IV 和密文都存储起来？
3、AES CBC 用来加密存储用户密码是否合适。
3、AES CBC 256bits 用来加密发送的消息或命令是否合适。

[cpdyj0]

不明白为什么不适用哈希方案呢？

[zyxk]

@cpdyj0 #1 管理系统，系统需要，希望之后是可以查询到密码的。

[hoyixi]

设计个安全的重置密码方案不行吗，非要解密密码？

[lqs]

应该分两个方面来考虑：
1. 客户端如何把密码传送给服务端
2. 服务端如何存储密码

[mason961125]

C/S 我觉得还是 公钥 /私钥 模式更好，算法告诉他，公钥给他，随便他弄都解不出来。

[cpdyj0]

似乎 IV 必须传递给服务器，只要 key 安全就没啥问题，那么建议服务端密码部分多设计下，和主业务部分隔离开。key 周期性更换，对各种读写做审计。

[cpdyj0]

哦，我脑残了，key 不可能不泄露，客户端需要加密。。。
那么建议楼上的非对称方案，同时保留哈希方案，用作一般登录校验，非对称只用来获取密码明文时使用，做审计。

[lovedebug]

aes cbc 刚爆出漏洞没多久吧

[cxtrinityy]

如果你的初始 iv、key、salt 什么的明文传输，那么 cbc 也没有意义吧，cbc 是链式的，只是拿前一块密文异或下一块明文后加密，又不是魔法，安全传输还是考虑下 https 比较好
到了服务器了，你是不是 cbc 也无所谓了吧

[Alexinder]

密码存储用 hash 不要用加密

[yzwduck]

3、不合适，绝对不要用可逆加来保存口令，一旦泄漏加密密钥，口令就立马变成明文。
4、不合适，加密传输还需要解决密钥交换等一系列问题，实现过程非常复杂。建议用已有的 TLS/HTTPS + 证书。

@lovedebug 能否请教一下最近 aes cbc 爆出了什么漏洞？

[msg7086]

@Alexinder 用 hash 只能验证密码，不能存储密码。

[zyxk]

@cxtrinityy #9 IV salt 传输 ,key 肯定不传输的。

[cxtrinityy]

@zyxk 对称加密不传 key 服务端不能解密吧，不是要服务端能解密？