Gen,
PasswordEncoder has been depreciated for some time now, but whether it will
be removed I am unsure. If passwords have been hashed its never going to
be an easy change as its a one way encryption. The changes if I remember
are mainly in the java classes so we could leave the old code and use
properties to control which one is in use.
ie changes are
from:
DaoAuthenticationProvider provider = (DaoAuthenticationProvider)
ctx.getBean("org.springframework.security.authentication.dao.DaoAuthenticationProvider#0");
String algorithm =
WebloggerConfig.getProperty("passwds.encryption.algorithm");
PasswordEncoder encoder = null;
if (algorithm.equalsIgnoreCase("SHA")) {
encoder = new ShaPasswordEncoder();
} else if (algorithm.equalsIgnoreCase("MD5")) {
encoder = new Md5PasswordEncoder();
} else {
log.error("Encryption algorithm '" + algorithm + "' not
supported, disabling encryption.");
}
if (encoder != null) {
provider.setPasswordEncoder(encoder);
log.info("Password Encryption Algorithm set to '" +
algorithm + "'");
}
......
to:
DaoAuthenticationProvider springProvider = (DaoAuthenticationProvider) ctx
.getBean("org.springframework.security.authentication.dao.DaoAuthenticationProvider#0");
if (springProvider != null) {
String theEncoder =
WebloggerConfig.getProperty("passwds.encryption.encoder");
if (theEncoder.equalsIgnoreCase("Standard")) {
encoder = new StandardPasswordEncoder();
} else if (theEncoder.equalsIgnoreCase("BCrypt")) {
encoder = new BCryptPasswordEncoder();
} else {
log.error("Failed to locate encoder using : " +
theEncoder
+ ", not supported, disabling encryption.");
}
if (encoder == null) {
encoder = NoOpPasswordEncoder.getInstance();
}
.......
}
I guess if we have both they will never want to change.
Cheers Greg.
On 27 January 2014 11:52, Glen Mazza <glen.ma...@gmail.com> wrote:
> If this configuration is done in XML: http://mprabhat.wordpress.com/
> 2012/07/20/spring-security-3-1-password-encoder-with-
> custom-database-and-jsf-2-0/, it may be sufficient to provide two XML
> blocks, one using the deprecated and one using the new, with the deprecated
> one commented-out. Then the install guide would tell people to uncomment
> the one and comment the other if they're upgrading from 5.0.x or
> earlier....?
>
> Glen
>
> On 01/27/2014 06:44 AM, Glen Mazza wrote:
>
>> If we have to, we have to--but how will people be able to upgrade from
>> 5.0.x to 5.1 without everyone's password being lost and hence locked out
>> (i.e., if blogs.oracle.com tried this all users would be locked out,
>> right?) Perhaps we can support both algorithms in 5.1 (
>> http://stackoverflow.com/a/17450276).
>>
>> But if we have to break it, let's use moving forward the best algorithm,
>> from the above link the BCCrypt() one apparently (unless you know
>> otherwise). Also, we don't have to use Spring here if plain Java offers
>> corresponding libraries (less likely to deprecate).
>>
>> Also, Greg, please answer this question I put in the comments (if you
>> know it), in case you missed it: https://issues.apache.org/
>> jira/browse/ROL-1795, we have the closing of a JIRA issue (always a good
>> thing :) on the line...
>>
>> Glen
>>
>> On 01/27/2014 05:23 AM, Greg Huber wrote:
>>
>>> Gentlemen,
>>>
>>> The class
>>> org.springframework.security.authentication.encoding.PasswordEncoder SHA
>>> and MD5 in RollerContext has been depreciated, it can be replaced by
>>> StandardPasswordEncoder(), BCryptPasswordEncoder() and
>>> NoOpPasswordEncoder.
>>>
>>> The down side is the encryption is based on the username and password
>>> (rather than just the password), so all passwords will need to be reset.
>>> Any objections on doing this upgrade?
>>>
>>> Cheers Greg.
>>>
>>>
>>
>
