一个想法 用非对称加密算法登录

你这有一个前提条件就是用户每次只会用这一个客户端注册账号和登录账号对吧

@xing393939 一个产品可以把自己的加密方式确定下来，这样的话对于用户来说就和其他的登录方式没什么区别了，像往常一样登录，只是服务器的数据库那里存的不是密码散列，而是公钥。要是自由点的话可以让用户选择自己喜欢的加密方式，不过这样的话，产品应该是面对懂点密码学的用户。

你的想法本来就有标准的

https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake

没搞清楚 LZ 说的……
首先……用户名密码怎么生成非对称密钥对？

还有，暴力破解 Hash 算法难道容易么？
能暴力破解，是因为用了彩虹表等手段（按我的理解它顶多算个体积超小的高效“字典”，制作它时还是需要付出苦力的，而且能覆盖的密码长度也很有限）
有时候用户的密码是 123456 之类容易猜的，或者已经通过别的途径泄露了，所以才有“撞库”之类手段，这不表示 hash 算法不安全吧。

你用私钥登录 SSH 不就这个逻辑嘛

U2F 也和你描述得差不多 https://en.wikipedia.org/wii/Universal_2nd_Factor
其实 RSA 之所以比密码安全还是因为 RSA 的密钥太长了，而这么长的密钥根本不可能记住，所以密钥的存放又是另外一个问题了。

补充一下我上面说的「更安全」是指爆破难度更高。

看一下 mega.nz

你们都没有用过银行的电子证书么……

starcom 就能用证书登陆啊

@ipwx 我的目的就是想不让服务器存密码散列，觉得这样不安全。
@acess 这只是一个初步的想法，RSA 是随机的选择大质数，而我是想凭借着账号密码来定向选择大质数，这就可以保证用同样的账号密码能登录。另外，我认为 hash 算法被破解是迟早的事，虽然现在有很多 hash 算法，而且如果用这个登录的话，彩虹表攻击是无效的。
@tony1016 我是参照 ssh 私钥登录的，但是私钥容易遗失，一旦遗失了就无法登录了，为了避免这个问题，私钥是需要用的时候才生成的。
@jybox 私钥是需要使用的时候才生成，所以不要保存私钥，但是要想出一种方法保证每次生成的私钥都相同。。

所以 (公钥, 私钥) = F(用户名, 密码)？

那不还是一个 hash 函数？只不过你换了一个 hash 函数。

加盐不好么？

@pwn #11 `hash 被破解`？ 一个信息熵减少的算法还能逆向？

`彩虹表攻击是无效的` (公钥, 私钥) = F(用户名, 密码) 和 加盐的 hash 有啥区别么？

`但是私钥容易遗失，一旦遗失了就无法登录了，为了避免这个问题，私钥是需要用的时候才生成的。` 还不是每次生成的都一样，拿到你的账号密码和直接拿到你的私钥一样吧？

你可以选用散列值很长的 hash 函数，和很长的盐，一样可以达到效果

1.登录之前获取 salt
2.客户端通过 salt 对密码进行加密
3.服务端通过 salt 对密码进行解密
4.翻译结果

数据库中存的是 客户端加密后的 + 服务对称加密后的密码。
这样依赖，即使脱裤，如果不知源码中的 密匙也是无法破解的，即使知道源码中的密匙，因为客户端用的是不对称加密，还是无法获取密码原值。

凭借账号密码生成大质数这一点应该是很难实现的。质数本身就不是通过某种公式生成出来的，只能筛选出来。

倒是可以生成私钥后用用户的密码加密。

@geelaw 这个方法是没有摆脱账号密码登录的这个体系，这是我认为这个方法的缺点之一，但我觉得最起码这个比 hash 好，因为两个一样密码的 hash 值是相同的，而采用这种方法两个一样的密码它们的公钥是不相同的。

@hxsf hash 不能逆向，但是之前看到 MD5, SHA1 都被破解过，虽然不知道具体用什么方法，所以觉得迟早会被破解，时间问题，暂时 SHA25, SHA512 这些还能安全比较久。

区别就在于`两个一样密码的 hash 值是相同的，而采用这种方法两个一样的密码它们的公钥是不相同的`。

拿到你的账号密码和直接拿到你的私钥是一样的，没有摆脱账号密码体系是这个方法的缺点。

@mrtctl 这样啊....那这个登录方法就不太可行了，我上学期学了密码学导论，没有讲得很细，所以就先假设有这个凭借账号密码生成大质数方法，这个方法也是登录的核心，既然没有的话，那只能想其他方法了。谢谢您了。

最好不要储存原密码！
只储存散列值，然后你爱怎么加密都可以。

@pwn #16 你加盐就可以让同一个密码的 hash 不同了。而且你这个方法和加盐的 hash 没啥不同，只是有一个特殊的：你的盐是用户名的函数。

@vainly #14 你这个模型里，攻击者不需要知道密码，只要知道密码加盐之后的 hash 即可。

类似的想法我很早以前就实现过了，基于 openpgp.js，过程比你的简单一些

服务器端随机生成密码，用公钥加密传给前端，前端用自己的私钥解密后用该密码登录，公钥在注册时上传

https://github.com/coyove/Libay/blob/master/auth/auth.go

@geelaw 盐是有过期时间的，加密后的 hash 在盐过期后是校验失败的。

@vainly 你可以在每次改变密码的时候换盐，但是好像没听说盐需要过期……

目前非对称加密的私钥不能"依靠"帐户密码生成，是筛选出来的大质数。其次，加盐是为了避免彩虹表"爆破 /碰撞"，盐没有过期这一说。而且能够使用彩虹表的前提是你已经被拖库了。第三，MD5(大约)十几年前就被我国山东大学的王小云教授带领的团队提出的密码云碰撞算法破解了，所以现在大家都用作签名而非加密。SHA1 则是位数不足导致以现在的计算机可以在可接受的时间内算出来所以被抛弃使用了。希望说"不知道具体用什么方法"之前可以先去查一下。
勘误结束，来谈谈用户密码的加密，这里存在一个问题，我们需要保留用户密码的所有信息么？如楼上某人所说，我们其实不需要保留用户密码的所有信息，熵减也是可接受的，只要熵减后的取值空间仍然足够大且分散，保证不同密码生成的 hash 值碰撞的几率足够小，不会出现我们密码不一样但是 hash 过后的值是一样的就可以了。也就是说密钥 /加 /解密算法的具体应用其实包含两方面，还原或验证，而用户用密码登录这个过程，我们需要从 hash 值"还原"出用户的原始密码吗？不，我们事实上只需要"验证"就可以了，验证的成本比还原要低的多，而对于窃取了你数据库的黑客来说，他必须还原或近似还原(记得熵减么？)出原始密码才行，那么他破解的成本要比我们验证高的多。
这里有另外一个问题，计算时间的问题，hash 算法往往是位运算级别的运算，非对称加密算法则往往涉及大数运算，这个中间的差别可是数量级级别的。你要考虑这中间的计算成本计算时间，黑客不能接受，但是你系统的用户就可以接受了吗？基于同样的理由，你的算法里面的客户端产生私钥这一条，所需的时间可能也是用户不可接受的(假设你需要的是一对足够健壮的 key-pair，比如 2048 位)。
那么最后说结论，综合起来，平衡破解难度与计算成本，目前广泛采用的方式仍然是 hash 算法，辅以每个用户独立的盐，以及 N 次迭代 hash，来放大彩虹表制作所需的成本以及难度，来避免被破解。建议参考，PBKDF2，bcrypt，scrypt。
回到问题的起点，我们目前所讨论的一切都是数据库被拖库以后的"补偿"安全措施，那么你为什么不避免数据库被拖库呢？安全问题的每一个链条都要做好。补丁要及时打，漏洞要及时补。碰到 0day，才是这个补偿安全措施该发挥威力的时候。
谈谈现实情况，现实情况是，绝大多数的用户密码泄漏事件都是因为用户在不同网站采用了相同的密码导致黑客拿别的网站泄漏的密码，轻松撞库撞出用户的密码。诚然这个是用户的安全意识问题，但是整体提高从业者的能力与安全意识，才是杜绝我前面这句话里的"别的网站"出现的一大措施。这也是我在这里普及这些安全知识的初衷。
以下则是对楼主的建议，尝试对业界现有方案进行质疑和挑战的精神值得鼓励和赞扬，但是前期功课一定要做好，这是对你自己负责也是对看你帖子的网友们负责。了解现在的方案是怎么提出和演化成现在这个样子的也很重要，以上几点做不好，很容易滑入民科的深渊，只谈挑战权威，不讲实验结果与事实，缺乏基本的理论知识和学术素养。
以上所有内容限于个人立场和眼界所限可能有谬误，还请楼下朋友斧正。

哦，对了，上面说的这些都是针对大规模信息盗窃的防范。假如是针对特定用户，其实社会工程学的可行性要高得多。做技术很容易陷入一切问题都想通过技术解决的怪圈，但人的问题才是核心问题。

@tlday 王小云，那个根本没有任何实用性，撞出来的东西，长度 特征 有可能完全不一样

盐过期只适用于会话 token。