Glen, I was not intending to do it as it would involve a lot of work for
existing blogs. We would need some kind of password change screen from old
to new when signing on, to help the migration.
I don't think there will be a compatible replacement as the hashing is
based on the username/password rather than just the password, ie it stops
copying/sql the password from user to user.
I guess it would be good to have two versions, legacy and username/password
based, so newer sites can adopt best practice.
I could see if I can add it via properties if needed.
Cheers Greg.
On 26 February 2014 00:30, Glen Mazza <glen.ma...@gmail.com> wrote:
> Greg, you haven't made this change yet, correct? Please hold off on this
> for the 5.1 series, we can do it in a later release. For one thing,
> there's a good chance if and when Spring finally removes this encoding
> option they'll put a similar, compatible option back in someplace else.
> But much more importantly, we want everyone to be able to upgrade as
> smoothly as possible to the new 5.1 when it's available so we won't have to
> maintain both 5.0.x and 5.1. As you know, 5.1 is significantly smaller &
> simpler than 5.0.x, and everyone's going to be glad if we can retire the
> 5.0.x series.
>
> Regards,
> Glen
>
> On 01/27/2014 09:00 AM, Greg Huber wrote:
>>
>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>
>
