[
https://issues.apache.org/jira/browse/JAMES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447289#comment-17447289
]
Karsten Otto edited comment on JAMES-3674 at 11/22/21, 1:30 PM:
----------------------------------------------------------------
I don't think we will need a separate salt column. bcrypt and friends usually
encode all necessary parameters in the password field itself, e.g.
{code:java}
$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy{code}
means use bcrypt algorithm (`$2a$`) with `2^10` rounds using salt
`N9qo8uLOickgx2ZMRZoMye` (salt length is fixed). For PBKDF2 there should be
something similar, maybe take a look at how passlib handles it.
Note that parameters differ among various hashing schemes; it is important to
record them in the database for each password, so upgrading to different
parameters or a different scheme is possible. Otherwise, people could again get
stuck with a scheme/parameter set.
In terms of this proposal, `algorithm` would be `bcrypt` and `hashingmode`
would be `plain` (sic!)
That is, unless someone insists on implementing an additional server-wide
secret to be included in the password hash, in which case `hashingmode` would
be `pepper`.
Otherwise, the `hashingmode` column is only relevant for simple hashes like
SHA-512, as will be present in the existing (and likely legacy) databases.
was (Author: kotto):
I don't think we will need a separate salt column. bcrypt and friends usually
encode all necessary parameters in the password field itself, e.g.
{code:java}
$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy{code}
means use bcrypt algorithm (`$2a$`) with `2^10` rounds using salt
`N9qo8uLOickgx2ZMRZoMye` (salt length is fixed). For PBKDF2 there should be
something similar, maybe take a look at how passlib handles it.
In terms of this proposal, `algorithm` would be `bcrypt` and `hashingmode`
would be `plain` (sic!)
That is, unless someone insists on implementing an additional server-wide
secret to be included in the password hash, in which case `hashingmode` would
be `pepper`.
Otherwise, the `hashingmode` column is only relevant for simple hashes like
SHA-512, as will be present in the existing (and likely legacy) databases.
> 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: 6h
> 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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
