假设我正在设计一个具有适度安全要求的web服务。在大多数情况下，威胁模型更多地是关于无聊的大学生，而不是你在间谍小说中找到的任何东西。使用以下密码存储方案会有什么实际问题吗？
salt||散列(站点||密码|| salt(
其中site是我的站点的唯一标识符，password是用户密码，salt是用户特定的随机salt，hash是像SHA-1一样的通用加密哈希函数，||表示串联。
我知道这个计划会带来一些问题。
-
散列的计算速度(设计为(很快，一次迭代就会让特定的弱密码成为猜测。
-
单独的连接可能会在哈希的整体输入中导致"双关语"。
现在，互联网上有一些安全专业人士会让我相信，如果这是我的一个足够好的密码哈希计划，我就不可能得到工作，我迫切需要回到学校。他们指出，从安全角度来看，有一些众所周知的密码哈希方案具有更好的性能。他们要求我换个更好的。
但真的，我应该吗？我有点反驳。
-
这可能不是我服务中最薄弱的环节。一个真正决心闯入的人还有很多其他途径，我应该优先考虑我的时间，以确保较弱的途径。
-
如果我的网站没有什么内在价值，那么成本效益已经对攻击者不利了。一个大型集群/僵尸网络可以在一天/一周内恢复一个弱密码，这在多大程度上是一个实际问题？当然，在那一天/那一周，它还有更有价值的事情要做。
-
由于木马程序、键盘记录程序、社会工程攻击等原因，泄露账户的可能性更大。技术并不是这种安全性的限制因素。
-
我的方案越复杂，移动/扩展到另一个平台可能就越困难。如果我使用bcrypt(假设(，我可能需要编写一个bcrypt包装器并将其合并。
我真的很喜欢这个计划。这真的很简单。执行很难出错。我认为，就一个普通网站的所有意图和目的而言，它应该是好的。要求我制定一个更好的哈希方案，听起来就像是要求我在一扇已经很容易受到链锯攻击的门上安装一把更大的锁。
如果我在这里做错了什么，我将非常感谢有人指出这一点，特别是在实际和现实世界中适用的问题方面。
谢谢。
如果数据库可以访问，那么salt和hashing有什么意义？
盐可以防止(一些(彩虹表攻击，但它们不能防止字典或暴力攻击。
使用Scrypt或bcrypt，其中Scrypt更强，但两者都使用工作证明系统，使破解密码更加困难。请参阅OWASP密码存储备忘单
从纯粹的哈希角度来看，除非我读错了你的问题，否则你建议创建一个与用户特定的随机salt连接的密码哈希，这是通常的方法。如果你已经有了足够长度的加密随机强盐，那么串联中涉及的任何额外数据都不会有太大的区别。
然后是关于哪种哈希算法最安全的古老争论，当然，bcrypt将胜过SHA，尤其是MD5，因为它具有自适应的原生特性，并且能够增加哈希过程的持续时间以抵御暴力攻击。
然而，您可以务实地辩称，对于大多数通用网站案例，SHA1及以上版本就足够了。当你看看我们最近看到的漏洞时，密码泄露通常发生在以纯文本存储(显然非常容易受到攻击(或无盐哈希(容易受到彩虹表的攻击(的情况下。当然，SHA导数的处理速度会更快(特别是如果它是一个单独的散列(，但与加密随机盐相结合，这不是一项小任务。
一个很好的例子是：Microsoft的ASP.NET成员资格提供程序使用SHA1，并且使用非常广泛。没有本机bcrypt支持(尽管有第三方库可用(，这可能会告诉你微软如何看待这个问题。
最后，还有密码强度的问题。设置一个长的、强的需求显然有助于对抗许多暴力技术的哈希强度。当然还有可用性的权衡，但这是另一个问题。