如图所示，在老系统上登录开启了双重验证的 Apple ID 时，会要求在密码后面直接附加上其他设备显示的六位验证码
求问，这是不是能说明苹果公司不是用摘要类算法存储我们的密码?如果不能，那么什么样的算法能够让苹果公司从拼接字符串的摘要中直接同时验证密码和验证码?
求问，这是不是能说明苹果公司不是用摘要类算法存储我们的密码?如果不能，那么什么样的算法能够让苹果公司从拼接字符串的摘要中直接同时验证密码和验证码?
This topic created in 3213 days ago, the information mentioned may be changed or developed.
 |
jasontseJan 16, 2018 via iPad
1
验证密码的时候去掉最后六位
|
 |
xuanboyiJan 16, 2018 via iPhone
2
分段验证？
|
|
xuanboyiJan 16, 2018 via iPhone
3
同意一楼，因为完全正确的话只有一种可能，密码和验证码都正确，而密码长度不可知，验证码的长度是固定的，所以只要方便验证应该就可以了吧
|
 |
FFLYJan 16, 2018
4
这个还算简单的，智能门锁的更复杂，输入密码的时候可以任意的输入掩饰码。
|
 |
ofnhJan 16, 2018 via Android
5
密码+token 的操作，很多大公司内部系统登陆方式也是这样的
|
 |
xiaolanglangJan 16, 2018
7
去掉后六位，前面的是密码，后面的是验证码
因为验证码是恒定六位的，所以做起来还是很容易的…… |
 |
bumzJan 16, 2018 via iPhone
8
储存的密码哈希，提交的密码加密但不哈希
这样服务器拿到老设备提交的密码就直接解密，分割就可以正常验证了 |
 |
TinkJan 16, 2018
9
后面去掉 6 位不行吗？
|
 |
10
|
|
xiaolanglangJan 16, 2018
11
@mario85 HTTPS 已经足够保证密码的安全了，没有必要在客户端就进行一次摘要操作的，我认为上传的就是原始的密码……
|
 |
dndxJan 16, 2018
12
@gy911201 显然是上传的原始的密码，如果在客户端哈希后再上传那哈希存储的意义就完全没有了，攻击者直接传哈希上来服务器无法得知到底客户端知不知道明文的密码。
|
 |
14
应该是
1.客户端哈希密码，2.客户端哈希（密码哈希+验证码），3.上传，4.服务器端哈希（存储的密码哈希+验证码），5.比对两个哈希值。 这样，攻击者拿不到密码原文和密码哈希，而且，加入验证码可以抗重放攻击。 |
1
Select Language