可以将用户的盐与密码哈希保存在同一个表中吗？

Posted 2023-02-24

【中文标题】可以将用户的盐与密码哈希保存在同一个表中吗？

【英文标题】：Is It okay to save user's salt in the same table as password hash?

【发布时间】：2011-09-16 08:35:33

【问题描述】：

没关系，不是没用吗？它可以保存在另一个表甚至另一个数据库中。

你怎么看？

附：为了更高的安全性，我也有恒定的盐“花生”。它是保存在配置文件中的常量值（不在数据库中）。因此，如果黑客想以某种方式破解密码，他还需要访问文件服务器和数据库。

【问题讨论】：

您的平台是否没有像样的登录/安全实施？不管你怎么想，重新发明这些东西都是有风险的。

我正在使用 Kohana，并且有现成的模块。这更多的是我自己的知识等等。

“我也有密码“花生”。你的意思是你有一个添加恒定盐“花生”？在这种情况下，这是有道理的（这就是您接受的答案解释它的方式）。

@mgiuca “花生”是指存储在文件服务器上的常量值。它使用密码和盐进行哈希处理。

好的，如果您不介意，我将编辑问题以将“密码”更改为“恒定盐”，因为“花生”并不是真正的密码。

【参考方案1】：

您想要存储 1) 每个用户的盐和 2) 散列密码 + 盐的结果）。您不想存储密码本身。

【讨论】：

对不起，你没有回答我的问题。 =P 我在问：“将用户的盐与密码保存在同一个表中是否可以？”。

@daGrevis - 我的回答是根本不能存储密码

密码我的意思是散列密码（使用带有盐和坚果的SHA-1）。

@daGrevis - 这是对有关安全最佳实践的问题的一个非常重要的澄清 :)

确实！我编辑了问题标题以包含“哈希”一词，因为这显然是提问者的意图。

【参考方案2】：

是的，可以将每个用户的 salt 存储在存储密码 hash（不是密码本身）的同一个表中 - 即使攻击者可以访问对于原始数据库数据，他仍然需要分别尝试每个用户的盐+密码；将盐存储在另一个表中并没有真正增加任何重要的安全性（如果您假设对手可以访问数据库，那么假设他只能访问其中的一部分对我来说没有多大意义）。

如果您使用 salt+peanuts+password 来创建密码哈希，那么我会说您的设计比 80% 的系统更安全——也就是说，相当安全，不会过度偏执.

---

但是请注意，如果您实际上是以可恢复的形式（加密或明文）存储密码，那么您将把任何安全措施都扔到窗外 - 盐和散列的全部意义在于您 不是以可恢复的形式存储密码。如果您确实存储了密码，那将是您系统中最薄弱的环节，这将是完全不安全的。说清楚点：用户表应该只包含 salt+peanuts+password 的 salt 和 hash，绝不能包含密码本身。 p>

【讨论】：

很好的答案！感谢“80% 的事情”。=]

我得到了盐和哈希，但花生是什么？

@Antony：他们和 salt 配合得很好；）这是一种引用每个应用程序 salt 的方式，可能存储在应用程序服务器上（这样在数据库受损的情况下，salt 的一部分仍然超出攻击者的掌握）。也称为“胡椒”，同样幽默。