[
https://issues.apache.org/jira/browse/SHIRO-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057358#comment-13057358
]
Les Hazlewood commented on SHIRO-277:
-------------------------------------
Hi Phil,
Thanks for offering to help out on this.
My belief is that most people will store the salt alongside the password as a
separate column, or even embedded in the password hash column itself. For
example, I've been working a little bit on supporting a unix crypt(3) format
for Shiro's user passwords in INI. In *nix crypt, all information necessary to
perform a password hash comparison is encoded in a single field via the Modular
Crypt Format [1].
Granted, this isn't as secure as splitting this information up in multiple
places (having it all in one place doesn't protect against brute force
attacks), but I believe it is well within the 80% of the 80/20 rule for most
end users.
So my expectation is that if either a separate column or embedded, that this
information would be retrieved as part of the single authentication query.
This would imply that the JdbcRealm should be refactored to allow for either
possibility. This can typically be done w/ one query, e.g:
1. If storing a crypt-style password hash, the existing query will work as-is.
The logic just needs to be changed to reconstruct the SaltedAuthenticationInfo
object based on the MCF tokens.
2. If the salt is a separate column, the query will need to be something like
"select password, password_salt from users where username = ?".
As for testing, we can use whatever dependencies we want (and as much of them
as we want) as long as they're ASF 2.0 compatible. Since test libraries don't
impact end user applications, we don't have to be as frugal with them. Feel
free to use whatever mechanism you prefer!
Does this help?
[1] http://packages.python.org/passlib/modular_crypt_format.html
> JdbcRealm needs to be refactored
> --------------------------------
>
> Key: SHIRO-277
> URL: https://issues.apache.org/jira/browse/SHIRO-277
> Project: Shiro
> Issue Type: Improvement
> Components: Realms
> Affects Versions: 1.1.0
> Reporter: Ilya Pyatigorskiy
> Fix For: 1.2.0
>
>
> There are at least 2 obvious problems:
> 1) the javadoc for JdbcRealm.setPermissionsQuery suggests that the query is
> expected to have 3 columns ("containing the fully qualified name of the
> permission class, the permission name, and the permission actions (in that
> order)"), but the code actually looks only for 1 - permission actions on
> index 0
> 2) it doesn't support salt - checks only for password matching
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
