在开源项目中对密码进行加盐处理
我正准备将一个项目公开放到github上。在我的项目中，为了进行登录身份验证，我采用一个字符串并将其强类型化为密码：
// Stripped down here on SO for brevity
public class Password
{
private const string salt = "sealab2021";
public Password(string password)
{
this.saltedPasswordHash = new MD5Hash(password + this.salt).ToString();
}
public string SaltedHash { get; private set; }
}
显然，如果盐是公开可见的，那么盐就毫无价值。
其他人如何在开源项目中对密码加盐并仍然安全地隐藏盐短语？
盐是否应该存在于文件系统上的某个位置并在应用程序启动时加载？似乎是一个合理的解决方案，但如果我要实际使用 github 进行源代码控制，而不仅仅是在新版本发布时转储到 github，则该文件仍然可供公众访问。
I'm preparing to put a project publicly on github. In my project, for login authentication, I take a string and strongly type it as a Password:
// Stripped down here on SO for brevity
public class Password
{
private const string salt = "sealab2021";
public Password(string password)
{
this.saltedPasswordHash = new MD5Hash(password + this.salt).ToString();
}
public string SaltedHash { get; private set; }
}
Obviously, if the salt is publicly-viewable, the salt's worthless.
What do other people do to salt passwords in open-source projects and still keep the salt phrase securely hidden?
Should the salt exist somewhere on the file system and be loaded when the application starts? Seems like a reasonable solution, but if I'm going to actually use github for source control and not just do dumps to github when new versions are released, that file's still going to be accessible to the public.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不正确。您应该假设盐可能被攻击者所知，而不是依赖于隐匿性的安全性。
您的错误是您为整个系统使用了单一的共享盐。您应该为每个用户使用单独的伪随机盐，然后将该盐与该用户的密码哈希一起存储。
我还建议使用 PBKDF2 或 bcrypt 而不是简单的加盐哈希。
Not true. You should assume that the salt is potentially known to an attacker, rather than relying on security-through-obscurity.
Your mistake is that you're using a single, shared salt for the entire system. You should use a separate, pseudo-random salt for each user, and then store that salt with the password hash for that user.
I would also recommend using a system like PBKDF2 or bcrypt rather than a simple salted hash.
首先，盐不需要保密。它们需要是随机的。盐适用于攻击者已经破坏数据库（通常还破坏文件系统）的情况。这意味着他们可以访问散列密码和盐。然而，盐仍然大大增加了获取明文密码所需的工作量。
更重要的是，登录盐应该是随机的，并且每个用户。创建用户时生成随机值。如果您想使用两种盐（每个用户一种，每次安装一种），请在安装脚本中生成一个随机值。
最后，这不是开源/专有问题。可以轻松地从专有软件对此类硬编码值进行逆向工程。
First, salts don't need to be secret. They need to be random. A salt is meant for situations when the attacker has already compromised the database (and often the filesystem). That means they have access to the hashed passwords and salts. However, the salts still greatly increase the effort needed to get the plaintext password.
More importantly, login salts should be random and per-user. Generate a random value when the user is created. If you want to use two salts (one per-user, and one per-installation), generate a random value in a setup script.
Finally, this is not a open source/proprietary issue. Such hard-coded values can easily be reverse-engineered from proprietary software.