我负责在我们的 .Net MVC 4 Web 应用程序中进行身份验证，并且在密码散列、存储和身份验证方面遇到了麻烦。
目前的计划是使用 2 个 Salts、1 个动态（每个用户）和 1 个静态（Web 应用常量）和一个强大的哈希函数。
给定一个包含用户名和密码的简单用户表：
我担心的是，这样做，我将不得不仅使用用户名从 Web 应用程序内存中的数据库中获取用户。是否存在某种可能存在问题的攻击？理想情况下，我希望这是一个一步/一个 SQL 请求身份验证。
我是不是太担心了？是否有“每用户”盐的替代方案，我仍然可以进行一步验证？
salt 可以与密码哈希一起存储，因此您可以为每个密码而不是每个用户创建一个 salt。密码哈希函数（如 BCrypt 或 PBKDF2 之类的慢密钥派生函数）的常见做法是将 salt 明文作为密码哈希的一部分返回，这意味着您可以将 salt 和哈希一起存储在单个数据库字段中。
要验证输入的密码，您首先必须搜索密码哈希（使用用户名或电子邮件），然后该函数可以从存储的密码哈希中提取使用的盐，并使用它来比较哈希。那实际上应该回答您的问题，数据库通常没有适当的函数来散列密码，因此您不能在 SQL 查询中进行验证，验证将在代码中完成。
第二种盐实际上称为胡椒，添加此服务器端密码的最佳方法是，使用此密码加密已经散列的密码。与散列相反，这将是一种双向加密，一旦有必要就可以交换密钥。
您不需要外部库来执行此操作。该框架内置了自己的 PBKDF2 实现。我更喜欢将盐存储在数据库中的单独字段中，但这只是我猜的口味问题。我在这里写下了我对密码哈希的想法