[
https://issues.apache.org/jira/browse/JAMES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446166#comment-17446166
]
Karsten Otto commented on JAMES-3674:
-------------------------------------
The point of this ticket and the associated pull request is to
# Introduce salting with minimal code change, so attackers are forced to
re-compute hashes vs. just looking them up in a rainbow table. Because *any*
kind of salting is better than none at all.
# Provide the simplest possible mechanism to upgrade older/weaker hashes to
newer/stronger ones, since even without salting, something like SHA-512 is
better than being stuck with MD5 forever. Or with the legacy hashing mode.
Re username change, my understanding is that James does not support it, i.e.
the name/email address *is* the account identifier, and if you want a different
one you need a new account. Thus this is not really an issue. Correct me if I
am wrong please.
Obviously, something like bcrypt would be even stronger, and a best practices
solution at that. However, it will definitely have a performance impact, which
is actually a feature in this case. Since I am not a core maintainer, I cannot
decide if the issue is worth it. Plus, people could always use an external LDAP
store for passwords, backed by whatever secure mechanism they desire. That
said, this PR does not prevent adoption of Password4j in the future.
> Support password salting and hash scheme upgrading
> --------------------------------------------------
>
> Key: JAMES-3674
> URL: https://issues.apache.org/jira/browse/JAMES-3674
> Project: James Server
> Issue Type: Improvement
> Components: UsersStore & UsersRepository
> Affects Versions: master
> Reporter: Karsten Otto
> Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently, James does not use salt during password hashing, so its password
> database is vulnerable to rainbow table cracking if someone ever manages to
> steal it. Furthermore, there is no mechanism to upgrade user passwords to
> stronger/different hashing once they are created (cf. legacy hashing mode).
> This is a problem for any installation that does not employ an external LDAP
> user database.
> A simple solution is to include the user name as salt in the password hash.
> For this purpose, the {{hashingMode}} choices in {{usersrepository.xml}}
> should include an new mode "salted" in addition to "legacy" and "default".
> Additionally, the database should include an explicit column in the user
> table, which specifies the {{hashingMode}} of the stored password, and is
> used during verification. However, when a user changes the password, the
> configured {{algorithm}} and {{hashingMode}} from {{usersrepository.xml}}
> will be used instead. This way, the database gradually upgrades over time to
> the preferred setting.
> T-Shirt size L.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
