关于网银随机抽取密码三位字符进行用户认证的密码存储机制问询

嘿，这个问题问得特别到位——不少人用过这种随机抽密码字符的登录方式，但很少琢磨背后的门道，我来给你拆解清楚：

先排除你最担心的情况：正规银行绝对不会明文存密码，一来违反全球几乎所有的金融合规要求，二来一旦数据库泄露，所有用户的密码直接裸奔，风险大到离谱。所以明文存储这种情况可以直接排除。

你说的没错，普通的哈希（比如MD5、SHA-256）是把完整密码哈希后存在数据库里，登录时需要输入完整密码，再哈希后比对。但这种网银每次只让你输3个随机位置的字符，显然没法用这种方式——总不能把每个可能的字符组合都哈希一遍存起来吧？那存储量爆炸，而且也不安全。

这种认证方式的关键，是把密码的每个字符和它的位置绑定后单独哈希，然后分别存储。举个简单例子：
假设你设置的密码是abc123，系统会对每个位置的字符做这样的处理：

• 第1位字符a：计算哈希值hash("位置1:字符a")，把这个值存在数据库对应字段里
• 第2位字符b：计算哈希值hash("位置2:字符b")，单独存储
• 以此类推，直到密码的每一位都生成对应的位置绑定哈希

当你登录时，系统随机要求你输入第3、5、6位的字符，你输入后，系统会：

1. 对你输入的第3位字符，计算hash("位置3:你输入的字符")
2. 对第5位字符计算hash("位置5:你输入的字符")
3. 对第6位字符计算hash("位置6:你输入的字符")
4. 把这三个计算出的哈希值，和数据库里存储的对应位置的哈希值比对——如果都匹配，就认证通过。

这种设计的妙处在于：

• 就算数据库被泄露，黑客拿到的只是每个位置的单独哈希，没法还原完整密码——因为每个哈希是和位置绑定的，就算破解了某一个位置的哈希，也只知道那一个位置的字符，没法凑出完整密码
• 每次登录只传输3个字符，就算传输过程被监听，拿到的也只是部分字符，下次登录要的位置不一样，没用
• 能有效防键盘记录器：记录器就算抓到一次输入的3个字符，下次登录的随机位置不同，记录的内容就失效了

安全问题在这里主要是补充验证层：一方面，当系统检测到异常（比如登录IP陌生、设备第一次登录）时，会触发安全问题验证，进一步确认是用户本人；另一方面，就算有人拿到了你的部分密码字符，也过不了安全问题这一关，提升了整体的安全性。

内容的提问来源于stack exchange，提问作者sandrows