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