java - 如何使用 Shiro 的 Salted AuthenticationInfo？

Question

我正在为我的应用程序开发一个身份验证组件。我正在使用带有加盐密码的 Apache Shiro API。

我在这个例子中使用盐创建了一个新用户:

ByteSource salt = randomNumberGenerator.nextBytes(32);      
byte[] byteTabSalt = salt.getBytes();   
String strSalt = byteArrayToHexString(byteTabSalt);         
String hashedPasswordBase64 = new Sha256Hash(inPassword, salt, 512).toBase64();

但我不明白我应该如何在 doGetAuthenticationInfo 方法中使用盐来验证用户。我的方法必须返回 SaltedAuthenticatedInfo，但我不明白我应该如何创建它。

我不明白 Credential Matcher 和 SaltedAuthenticateInfo 之间的联系。

创建密码盐时是否必须通知凭据匹配器？

感谢您的帮助。

Answer 1

SaltedAuthenticationInfo

SaltedAuthenticationInfo 是一个接口(interface)。为了方便起见，Shiro API 提供了许多默认实现。尽可能尝试使用其中一种默认实现；避免创建自己的。
我建议 SimpleAuthenticationInfo 实现的不仅仅是 SaltedAuthenticationInfo 但可能足以满足您的目的。
参见 org.apache.shiro.authc.SimpleAuthenticationInfo想要查询更多的信息。

如果您确实需要实现自己的SaltedAuthenticationInfo，则应仔细阅读文档。
参见 org.apache.shiro.authc.AuthenticationInfo和 org.apache.shiro.authc.SaltedAuthenticationInfo想要查询更多的信息。

HashedCredentialMatcher

boolean doCredentialsMatch(AuthenticationToken, AuthenticationInfo) 实际上负责验证逻辑。
此方法采用 AuthenticationToken 形式的用户提交凭据，并将它们与以前存储的 AuthenticationInfo 形式的凭据进行比较。
不过，您必须确保首先将所有必要信息传递给 HashCredentialMatcher(迭代、算法和 SaltedAuthenticationInfo 中的盐)。

伪示例使用，

final int iterations = 50000;

AuthenticationToken authToken = ...;
SaltedAuthenticationInfo saltedAuthInfo = ...;

HashedCredentialsMatcher authenticator = 
     new HashedCredentialsMatcher(Sha256Hash.ALGORITHM_NAME);
authenticator.setHashIterations(iterations);

final boolean successfulAuthentication = 
     authenticator.doCredentialsMatch(authToken, saltedAuthInfo);

参见 org.apache.shiro.authc.credential.HashedCredentialsMatcher获取更多信息。

其他安全注意事项

• 盐长
  256 位盐看起来不错。使用这么大的盐，您可以最大限度地降低任何两个用户共享相同盐的风险。选择盐长度时请记住 Birthday Paradox发挥作用。

• 迭代次数
  根据经验，您应该永远使用少于 10,000。您目前使用 512，

  String hashedPasswordBase64 = new Sha256Hash(inPassword, salt, 512).toBase64();
  

  大多数散列算法都非常快(包括 sha256)，您不想为任何潜在的黑客提供任何帮助。您使用的迭代次数越多，验证速度就越慢，但它也会直接减慢破解尝试的速度。

  您将希望将迭代次数设置得尽可能高，同时仍然为您的应用程序保持可接受的响应速度。您可能会惊讶于自己能达到多高。
  我个人倾向于使用数百万；但我很偏执，不介意稍有延迟
  参见 Key Stretching了解更多信息。

• 就我个人而言，我会避免对任何散列参数(散列算法、salt 大小、迭代次数等)进行硬编码
  通过对这些值进行硬编码，您会限制您立即适应和响应的能力。

  将这些值与散列凭据一起存储可让您进行更动态的身份验证，您可以在未来以相对较少的努力配置和推出更强大的算法。

  例如，您的默认哈希算法可能是使用 50,000 次迭代和 256 位盐的 sha256。 future 虽然 50,000 次迭代可能还不够。
  无需大惊小怪，您就可以将首选算法配置更改为对所有新密码迭代 100,000 次。您不必担心会破坏旧密码，因为您不会更改使用现有凭据存储的算法参数。 您还可以使用它来更改 salt-size 甚至完全更改算法。

  如果需要，您可以让每个人都更改他们的密码；强制用户选择新的(希望更强大的)首选算法设置。
  Unix 操作系统多年来一直通过 /etc/shadow 做到这一点.

  前期需要付出更多努力，但值得投资。强大的身份验证控制至关重要。