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. >>>>>> >>>>>> >>>>>> >> >