假设我正在设计一个具有适度安全要求的Web服务。在大多数情况下，威胁模型更多的是关于无聊的大学生，更少关于你在间谍小说中找到的任何东西。使用以下密码存储方案会有什么问题吗？
盐|| hash（site || password || salt）
其中site是我站点的唯一标识符，password是用户密码，salt是用户特定的随机salt，hash是一个通用的加密哈希函数，如SHA-1和||表示连接。
我知道这个方案存在某些问题。
散列是（设计为）快速评估，一次迭代会留下特定的弱密码可猜测。
单独连接可能会导致哈希的整体输入中出现“双关语”。
现在，互联网上有一些安全专业人员会让我相信，如果这是我对密码散列计划的理解，我就不可能得到就业，迫切需要重返校园。他们指出，从安全角度来看，有众所周知的密码散列方案具有更好的属性。他们要求我改用更好的东西。
但是真的，我应该吗？我在这里有一些反驳论点。
这可能不是我服务中最薄弱的环节。真正决心闯入的人有很多其他途径，我应该优先考虑我的时间来保护弱者。
如果我的网站内在价值很小，那么成本效益已经对攻击者有利了。一个大型集群/僵尸网络可以在一天/一周内恢复一个弱密码是多少实际问题？当然，每天/每周都有更多有价值的事情要做。
由于特洛伊木马程序，键盘记录程序，社交工程攻击，你有什么可能会发生妥协的帐户。技术不是这种安全的限制因素。
我的方案越复杂，移动/扩展到另一个平台就越困难。如果我使用bcrypt（假设），我可能不得不写一个bcrypt包装并合并它。
我真的很喜欢这个计划。这很简单。实施很难出错。我认为，对于一般网站的所有意图和目的，它应该没问题。请求我提出一个更好的哈希计划，这听起来像是要求我在一个已经非常容易受到链锯影响的门上安装一个更大的锁。
如果我在这里做错了什么，我会非常感谢有人指出它，特别是在实际和现实世界适用的问题方面。
感谢。
答案 0 :(得分：2)
请参阅What is the point of salt and hashing if database is accessible?
Salts防止（某些）彩虹表攻击但是他们不会阻止字典或暴力攻击。
使用Scrypt或bcrypt代替，其中Scrypt更强大，但两者都使用Proof of Work系统来破解密码更加困难。请参阅OWASP Password Storage Cheat Sheet
答案 1 :(得分：0)
从纯哈希的角度来看，除非我错误地阅读你的问题，否则你建议创建一个密码的哈希值，该密码与用户特定的随机盐连接，这是常用的方法。如果您已经获得了足够长度的加密随机强盐，则串联中涉及的任何其他数据都不会产生很大的差异。
然后有关于哪种哈希算法最安全的旧论证，当然bcrypt将胜过SHA - 尤其是MD5--因为它具有自适应原生能力并且能够增加哈希处理持续时间以抵御暴力攻击
但是，您可以务实地争辩说，对于大多数通用网站案例，SHA1及以上就足够了。当你看到我们最近看到的漏洞时，密码泄露通常发生在它们以明文形式存储（显然非常脆弱）或者没有盐的情况下进行散列（很容易受到彩虹表的影响）。当然，SHA衍生物将更快地完成（特别是如果它是单个哈希），但与加密随机盐组合，这不是一个小任务。
例证：来自Microsoft uses SHA1的ASP.NET成员资格提供程序，并且使用非常广泛。没有本机bcrypt支持（虽然第三方库可用），这可能会告诉你微软如何看待这个问题。
最后，还有密码强度问题。设定一个长期强烈的要求显然会有助于哈希对抗许多暴力技术的力量。当然有可用性权衡，但这是另一个问题。