手机号用 rsa 加密后存储在数据库中,如何用手机号登录？

再存个 hash 值？

把手机号再用同样的密钥加密一次再传过来比对不就好了？如果没加盐的话

@zonyitoo 关键是数据库存的是加密后的哈希值,
用户输入的是明文,哈希值每次都不一样的
这咋写 where 条件啊，用明文去匹配加密后的值 行不通呀

@xujinkai 主要是哈希值每次结果都不一样

看到这个 ，也启发了我 ， 我也在代码里面傻傻的把密码加密了 。 存密码时候同时存一个明文的 hash 值
保存
1. 数据库中手机号=rsa （手机号）
2.保存 hash =md5 （手机号）
这个数据库中就有一个加密的手机号和手机号对用的 hash 值

使用时候
用 md5 （手机号） 的 hash 值获取对应记录，然后在解密手机号后对比

如果考虑到 md5 加密不安全，加盐 或者用对称加密


楼主这个是搞金融？

非对称加密的每次结果都是不一样的

@xxbutoo 你存的时候算 手机号的 哈希值 ，不是加密后的

为什么要用 RSA 这种非对称算法做加密呢？用对称算法不行么？

需要使用手机号登录，为啥还折腾加密哈希？伪需求吧

没什么思路好说的，只有明文或类明文才能实现。
否则只要是加盐的哈希，只能查全表来匹配。

@jzmws 确实，我考虑很久 也决定不用 rsa 加密了，用 aes 就行
主要是登录的时候 需要用明文去匹配数据库存储的值
rsa 的话安全是保障了 但是一旦用 rsa 加密了手机号，登录的时候就蛋疼了，只能用 aes 加密 可以用加密后的数据去匹配数据库中的字段

@xxbutoo 用 RSA 和 AES 两个一起做吧 因为 你把手机号加密了 肯定不好搞

字段用同一个 rsa 公钥加密就好，非得每行每个字段都用不同的公钥那就没办法了。。。

想过这个问题，每个手机号前面三位后面两位作为明文提示，中间六位加唯一盐存哈希值，不幸泄露被硬破的话，每个号码有一百万种可能

加密对比啊，跟 md5 密码单向加密一样用。比较密文即可

@wdlth 对称加密 aes 每次加密后的结果也是不同的

@opengps md5 不是摘要算法么

对称加密相同输入，输出肯定相同啊。怎么会不同呢？

登录存一份哈希就行了，多大点事…

用手机号登录，那手机号就是账号，没必要加密啊

@dzdh 用于文件检验是摘要，用于密码不可逆加密算加密算法

没有搞懂 Point，还请指教。
1.用户隐私起见:手机号应该是特定的场景下才会 Query,而不是当作 Username 。且，若使用 RSA 加密，公钥与私钥的分配是怎样的？掌握在用户手里还是自己手里？看见 Tag 里的 Go，莫非是 Blockchain ？
2.业务起见:对手机号进行加密在保证性能的评价下，有且只有给予用户 id 的方法来保证速度，换个思路，有没有可能 Register 时直接使用 GPG 生成密钥，敏感时使用服务器 Gennerate 一个文件(实时更新且设定过期)，使用 gpg 签名后，服务端解密并查表确认用户身份？(最近迷上了密码学，有些天马行空的想法，哈哈)

用户有私钥和没私钥是 2 回事。
如果用户有私钥，rsa 加密就变成解题。可以配合手机验证码验证身份。
用户没私钥的话，安全责任又在服务器这里的话为什么不选择对称加密呢？

需求拆分下，你的需求就是两个了，第一个是手机号用 rsa 加密存入数据库，第二个是手机号登录验证，所以第二个需求你不用非对称加密就行

还不如用 md5 呢，这样就密码泄露了还不至于把用户的直接也丢了(当然跑一次也很简单)

就是 1 楼的方法，再存一个手机号的 hash 。

手机号明文的 hash，密文再 hash 有个鸟用。

如果你觉得直接 md5 不够“安全”，建议加 salt 后再 md5，然后这个盐你自己爱怎么保护就怎么保护，效果差不多。

手机号 有必要加密？？？

不管你用什么加密方式，用到的密钥从哪里获取？

如果密钥就在服务器里，这和明文保存有什么区别？

如果要保护隐私，想来想去只有两个办法：1.不要用手机号登录； 2.手机号像密码一样存哈希值（比较耗资源）。

哈希不是加密，但如果你把密钥和密文放在同一个地方，则是比哈希更糟糕。

RSA 有两种算法，一种是加密，一种是签名。你想每次加密后 hash 值不变，用签名就可以。
加密算法无非是加入随机数，让每次结果不一样。

变的原因是应该 padding 算法 使用零填充试试

其实怕 hash 碰撞出来 可以考虑 hmac

再存一个手机号明文的 hash，然后对比明文的 hash 。

@Co1a 还不是我朝，普通用户都习惯直接用手机号登录你能不搞？李彦宏说的有道理的。

现在怎样判断手机号重复注册的问题

传到后台的时候解下密存成 hash，这样搞简单也不算不合规，毕竟人眼看见的不是明文。

@dzdh AES 算法在相同的分组模式、填充模式和参数下结果是一致的，不然怎么解密还原呢？

@idoggy 可以直接把 hash 后的值给 NSA 吗，10 个数字的话，假设一秒钟能尝试 1000 次，算一个月就能跑出来了

这个设计简直是............... 这么存和存明文有什么区别？

除非有明确要求要达到某加密级别，否则考虑 RSA 的加密效率和复杂性，用 RSA 来做验签的场景更多一点，手机号或证件号等敏感信息还要涉及登录用哈希加盐更适合。

有两个问题：1 密文需不需要还原明文手机号？ 2 每个用户是否要用不同的公私钥？

假设还原明文，是不同的公私钥，登录不能传输任何可直接还原出手机号的数据
用手机号本身生成 salt，计算出一个哈希值，hash = sha1( 固定 salt+手机号+sha1(手机号)+md5(手机号)（作为自身 salt ） )
每一条记录对应的 ras 的公钥私钥本身也需要存储对吧
用上面的 hash 值作为私钥的索引，每次登录由前端计算后回传，存在此索引表明此手机号存在，找到对应私钥解开密文得到原始手机号

上面计算的 hash 本身回传时可以再加密一次，登录页临时生成一对 rsa 的公私钥用于回传加密
如果手机号数据不用于短信等需要明文的场景，必须由用户输入手机号的操作才能还原，开发有代码有 rsa 公私钥也不能还原手机号的情况，可以在存储时，用上面 hash 值做 aes 的 key 加密后，再用 rsa 存储，rsa 私钥索引使用 sha1(hash)

不太明白这需求的出发点和目的是什么，先搞明白需求，再改设计

登陆的时候将手机号先用 rsa 加密对比下是否一致不行吗

我想了想，我要调用第三方短信接口的时候应该怎么办呢

我存的 base64..