[
https://issues.apache.org/jira/browse/JSPWIKI-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138258#comment-18138258
]
ASF subversion and git services commented on JSPWIKI-1231:
----------------------------------------------------------
Commit b51ca7d127241b3b6c246516b286e2a73db11376 in jspwiki's branch
refs/heads/dependabot/maven/tomcat.version-11.0.27 from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=b51ca7d12 ]
JSPWIKI-1231 Make the password hash algorithm and iterations configurable
New passwords were always stored as PBKDF2-HMAC-SHA256 with a fixed iteration
count. jspwiki.credentials.hash.algorithm (PBKDF2-SHA256, the default, or
PBKDF2-SHA512) and jspwiki.credentials.hash.iterations now set both, for the XML
and the JDBC user databases. The iteration count defaults to 600000 for SHA-256
and 210000 for SHA-512. An unsupported algorithm or an iteration count that is
not a positive number is logged and replaced by the defaults.
Entries already stored keep verifying whatever algorithm and iterations they
were created with. When a user logs in successfully and the entry does not have
the configured algorithm and iterations, the password is hashed again with them,
as it already was for the older SHA formats. Password reuse detection
understands
every supported algorithm.
A PBKDF2-SHA512 entry is up to 135 characters long, so the password column of
the users table is widened from 100 to 255 characters in the sample schemas.
Existing JDBC deployments have to widen it before choosing SHA-512, which the
property documentation says.
CryptoUtil gets the algorithm-aware methods and keeps the existing ones.
> UserDatabase password storage mechanism should be adjustable and not fixed on
> SHA-256
> -------------------------------------------------------------------------------------
>
> Key: JSPWIKI-1231
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1231
> Project: JSPWiki
> Issue Type: Improvement
> Reporter: Alex O'Ree
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.1
>
>
> There's stronger hashing available now and we should not be fixed in time to
> a specific hash algorithm. let's make it adjustable if possible or at least
> provide stronger options
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
