Sim, eu sei que Shiro deve estar bem para segurança com SHA256 e várias iterações, mas realmente não há uma boa desculpa para ele não suportar bcrypt. De qualquer forma, eu tinha um aplicativo legado que armazenava muitas senhas em bcrypt, que eu não podia (obviamente) ler ou portar para SHA, então realmente precisava de bcrypt. Felizmente, era mais ou menos trivial conectar o meu PasswordMatcher
:
package ca.uhnresearch.pughlab.tracker.security;
import org.apache.shiro.authc.AuthenticationInfo;
import org.apache.shiro.authc.AuthenticationToken;
import org.apache.shiro.authc.UsernamePasswordToken;
import org.apache.shiro.authc.credential.CredentialsMatcher;
import org.mindrot.jbcrypt.BCrypt;
public class BcryptPasswordMatcher implements CredentialsMatcher {
@Override
public boolean doCredentialsMatch(AuthenticationToken token, AuthenticationInfo info) {
UsernamePasswordToken userToken = (UsernamePasswordToken) token;
String password = new String(userToken.getPassword());
char[] credentials = (char[]) info.getCredentials();
String hashed = new String(credentials);
return BCrypt.checkpw(password, hashed);
}
}
Isso injeta multa na credentialsMatcher
propriedade de, por exemplo JdbcRealm
,.
Agora posso simplesmente mover o banco de dados com hashes e todos os usuários existentes permanecem felizes.