[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] [Comment Edited] (JAMES-3674) Support password salting and hash scheme upgrading
From:       "Karsten Otto (Jira)" <server-dev () james ! apache ! org>
Date:       2021-11-22 13:31:00
Message-ID: JIRA.13412323.1637167402000.47379.1637587860018 () Atlassian ! JIRA
[Download RAW message or body]


    [ 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 &amp; 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]