First, thanks for providing a lot of information for this question - it makes providing an answer a lot easier.
By looking at your sample database row list, it does not appear that you are storing the output that the PasswordService expects when performing a hashed password comparison. For example:
$ java -jar ~/.m2/repository/org/apache/shiro/tools/shiro-tools-hasher/1.2.2/shiro-tools-hasher-1.2.2-cli.jar -p
Password to hash:
Password to hash (confirm):
$shiro1$SHA-256$500000$uxaA2ngfdxdXpvSWzpuFdg==$hOJZc+3+bFYYRgVn5wkbQL+m/FseeqDtoM5mOiwAR3E=
The String that starts with $shiro1$
is what you would save to the password
column in the database. There is no need for a separate salt column as all the information Shiro needs is in the $shiro1$...
String.
The DefaultPasswordService
uses the same default configuration parameters (SHA-256, 500,000 iterations, etc) so if you use the Hasher CLI tool as I've shown above (no extra hash algorithm config), you don't need to customize the DefaultPasswordService
POJO any further. However, if you change the hashing parameters on the CLI, you need to ensure that the same parameters are configured on the DefaultPasswordService
bean (and/or its internal HashingService).
If you are still in testing and can change your DB schema, I'd recommend doing that now to have a single password field that stores the $shiro1$...
string. Then you use the PasswordService as documented here under Usage: