drmike01 is correct, the passwordService should be favored over the hashedCredentialsMatcher as of shiro 1.2.
However, you also allude to a more fundamental question: "Can't users simply edit the ini file and add roles to their account, thus giving them unauthorized access?" The answer to this, of course, "yes". If they have access to the ini file. But to be honest, if your users have access to edit the security configuration, whether or not they can change their roles is the least of your concerns. They can change way that authentication is done, change passwords, etc. In general, you have other protections that will protect your security configuration (no access to your server, filesystem permissions, etc). Hope that helps, Jared On Tue 19 Jun 2012 07:29:08 PM CDT, drmike01 wrote: > I think that section is a bit dated (for Shiro 1.1, I would guess). Shiro > 1.2 has a PasswordMatcher service that is much simpler to use. The relevant > bits from shiro.ini would look something like: > > passwordService = org.apache.shiro.authc.credential.DefaultPasswordService > # configure the passwordService to use the settings you desire > passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher > passwordMatcher.passwordService = $passwordService > # Finally, set the matcher on a realm that requires password matching for > account authentication: > myRealm.credentialsMatcher = $passwordMatcher > > By default, this uses a random salt, multiple iterations, and SHA-256, so > it's much more robust than what you found, and much simpler to use. > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Is-password-hashing-enough-tp7577522p7577523.html > Sent from the Shiro User mailing list archive at Nabble.com.
