苹果是怎么做到识别密码后附加的验证码的?

验证密码的时候去掉最后六位

分段验证？

同意一楼，因为完全正确的话只有一种可能，密码和验证码都正确，而密码长度不可知，验证码的长度是固定的，所以只要方便验证应该就可以了吧

这个还算简单的，智能门锁的更复杂，输入密码的时候可以任意的输入掩饰码。

密码+token 的操作，很多大公司内部系统登陆方式也是这样的

@FFLY 这个创意不错，由于门锁是不联网的设备，直接明文保存密码然后正则匹配就可以了。可惜联网的设备不能用这招。

去掉后六位，前面的是密码，后面的是验证码
因为验证码是恒定六位的，所以做起来还是很容易的……

储存的密码哈希，提交的密码加密但不哈希

这样服务器拿到老设备提交的密码就直接解密，分割就可以正常验证了

后面去掉 6 位不行吗？

@jasontse
@xuanboyi
@gy911201
是这样的，在 iCloud 界面登录时，第一次输入原始密码，点击登录，苹果返回提示需要输入验证码；然后返回到原来的界面（即第一次输入原始密码的界面），重新输入密码并在后面加上验证码，点击登录
如果密码只是存储时作摘要，提交时为非摘要加密或不加密提交（即全靠 https 保证数据不被抓到），那直接去掉后六位是可行的，就不会有这样的疑问了
但是有没有可能是，提交前就已经被摘要了，到了苹果那边只能看到摘要。那如果是这样的话，只能看到摘要的情况下怎么分开验证码和密码？

@mario85 HTTPS 已经足够保证密码的安全了，没有必要在客户端就进行一次摘要操作的，我认为上传的就是原始的密码……

@gy911201 显然是上传的原始的密码，如果在客户端哈希后再上传那哈希存储的意义就完全没有了，攻击者直接传哈希上来服务器无法得知到底客户端知不知道明文的密码。

@bumz
@gy911201
@dndx
感谢回复，看来应该是这样的了

应该是
1.客户端哈希密码，2.客户端哈希（密码哈希+验证码），3.上传，4.服务器端哈希（存储的密码哈希+验证码），5.比对两个哈希值。
这样，攻击者拿不到密码原文和密码哈希，而且，加入验证码可以抗重放攻击。

@gy911201 #10 客户端加密也有一丁点用，比如遇到能够读取明文但不能篡改的 HTTPS 协议漏洞（如 heartbleed ）的时候 233

@htpki
但是“客户端” iOS 6 iCloud 的逻辑，苹果是改不了的，而这个双重验证明显是后来才出的功能
所以应该是楼上说的，客户端不做哈希了