You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Greg Huber <gr...@gmail.com> on 2014/01/27 11:23:52 UTC
Spring password encoder depreciated
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.
Re: Spring password encoder depreciated
Posted by Greg Huber <gr...@gmail.com>.
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 <gl...@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 <gl...@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.
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: Spring password encoder depreciated
Posted by Glen Mazza <gl...@gmail.com>.
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 <gl...@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.
>>>>>
>>>>>
>
Re: Spring password encoder depreciated
Posted by Glen Mazza <gl...@gmail.com>.
For your below suggestion, I'm not sure how the code can go from an
explicit MD5 or SHA encoder to a generic StandardPasswordEncoder() and
still work. I think your solution is OK otherwise.
Another solution I'm thinking of is adding a new column "BCPassword" or
whatever to the Roller User table with no user option to choose
encryption method. Upon login, if and only if BCPassword is null, check
vs. the current password column using the old encryption algorithm. The
moment a user makes a password change, fill in the BCPassword column and
from then on rely on that column alone for authentication. With this
method, we can exhort all users to change their password to make sure
the BCPassword column is all filled up, so for a future Roller release
without the old auth mechanism, it won't matter because everyone will
have the BCPassword field filled (if not, then an Admin will have to
manually change the user's password for the holdouts.) How does that sound?
But this issue is probably not urgent. Spring will keep this value for
probably a few more years, and if not, we can stay on the present Spring
security version for quite some time (we're already at the latest and
greatest.)
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 <gl...@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.
>>>>
>>>>
Re: Spring password encoder depreciated
Posted by Greg Huber <gr...@gmail.com>.
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 <gl...@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.
>>>
>>>
>>
>
Re: Spring password encoder depreciated
Posted by Glen Mazza <gl...@gmail.com>.
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.
>>
>
Re: Spring password encoder depreciated
Posted by Glen Mazza <gl...@gmail.com>.
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.
>