StackOverflow 上有很多关于简单、无数据库登录系统的问题。我正要在a recent one 上建议一种加盐哈希方法，当我想：“这样做真的有意义吗？”。
多年来，我一直在数据库中存储加盐哈希，并且我理解它为什么更安全：如果数据库遭到破坏，它包含的信息将不允许任何人登录我的系统（与我存储纯文本时不同）数据库中的密码）。
但是在不涉及数据库的设置中，散列+加盐是否提供任何安全优势？我能想到的唯一原因是，如果攻击者获得了对我的服务器端代码的只读访问权限，就不可能找出任何密码。这是一个可能的情况吗？因为只要攻击者获得对文件的写入权限，他就可以做任何事情。
所以我的问题是：在设置非常简单、无数据库的登录系统时，密码应该加盐/散列，还是只存储为纯文本？
【问题讨论】：
标签： language-agnostic passwords
是的，它仍然为散列和盐它们提供了好处。如果脚本的源代码被泄露，人们可以简单地使用硬编码密码或 google 进行哈希，并可能找到输入值。使用加盐哈希两者都不可能。
【讨论】：
如果您能找出“我的源代码被攻击者读取的可能性是否明显低于数据库？”的答案，我认为这个问题已经为您解答。
我建议它不是 - 也许您的源不太可能泄漏，这取决于备份的方式等。即便如此，我怀疑它泄漏的可能性要小得多，以至于您可以忽略风险，因为不要忽视数据库的相同风险。数据库中的密码应该被加盐/散列的原因并不是因为数据库的某些特殊属性意味着攻击者可以查看其内容[*]，而是攻击者可以以一种或另一种方式查看各种事物。
事实上，源代码甚至可能比数据库更多泄漏，因为任何在系统上工作的人都可能需要访问源代码，而并非每个在系统上工作的人都一定需要访问实时数据库的内容。并不是说我认为您的开发人员不诚实（如果他们是，您遇到的问题比密码泄露更严重），只是围绕共享源的后勤工作可能会引入更多（或只是不同）可能意外泄漏的方式，而不是围绕备份的后勤工作一个数据库。
就个人而言，在您的情况下，我会在服务器上创建一个小文件，其中包含散列/加盐密码，几乎没有其他内容。安装不同应用程序实例的用户可以生成他们自己版本的此文件，其中包含他们自己的密码，与实际应用程序代码分开。他们应该使用与源代码相同的写访问限制来锁定它。
您是否将此文件称为“只读数据库”或“服务器代码的一部分”并不影响攻击者查看它的难易程度，尽管它可能会影响您是否将密码称为“硬编码”。
[*] 当然，对于特定的数据库、SQL 注入攻击或其他什么，存在一些特殊的潜在缺陷。这些不是数据库中的密码应该被加盐和散列的决定性原因。
【讨论】：
好吧，正如史蒂夫·杰索普已经概述的那样。源代码可能会泄漏或更有可能落入某些人手中。如果您对密码进行硬编码（我所理解的），那么为什么不将其存储为两部分的数据结构 => 使用的盐和散列密码。你知道它，但它从未出现在源代码中。这也是人们对数据库连接字符串或类似内容所做的事情。使用位于其下方变量中的密钥对其进行加密。因此它永远不会出现在源代码中。除非刚刚越过，否则甚至可能不在内存转储中。
【讨论】：