[Geoserver-devel] GWC password encryption and changing the encryption mode

Hi,
I’ve just committed the bug fix for GWC passwords not being encrypted:
https://github.com/geoserver/geoserver/commit/b63b6a2e540fdfb490d58a1a5e7e3dc5aea3a5e3

One of the things I’ve implemented is making sure the password gets re-encoded as the global password encryption method is changed, using a SecurityManagerListener.

That works fine, however there is an annoying side effect: the post change event also gets triggered on startup, the event tells me nothing about an eventual change of the password encoder, and the standard password encoder does not produce stable passwords.
Long story short, the event handling code ends up thinking the password encryption method changed, and rewrites the config file.

Not a show stopper, but if one manages the gs configuration via version control, that will generate a local change which will result in conflicts at the next data dir update.

So I’m wondering, is it really necessary to trigger the post changed event in the init method?
As far as I can see there is nothing using it.

An alternative could be to provide the listener both the old and new config, and let them deduce that the event is an init one because there was no config previously

Opinions?

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


Hi Andrea

  1. Our password encoders never produce the same result for identical plain text passwords. The encoding uses a random salt.

  2. The post changed event is used by GeoServerSecurityFilterChainProxy to create the internal data structure for the filter chains.

  3. What about checking the encrypted password with GeoServerPasswordEncoder.isResponsibleForEncoding(…). If the current config password encoder is responsible for the encrypted password, you can skip the recode logic.

Cheers
Christian

···

2013/7/5 Andrea Aime <andrea.aime@anonymised.com68…>

Hi,
I’ve just committed the bug fix for GWC passwords not being encrypted:
https://github.com/geoserver/geoserver/commit/b63b6a2e540fdfb490d58a1a5e7e3dc5aea3a5e3

One of the things I’ve implemented is making sure the password gets re-encoded as the global password encryption method is changed, using a SecurityManagerListener.

That works fine, however there is an annoying side effect: the post change event also gets triggered on startup, the event tells me nothing about an eventual change of the password encoder, and the standard password encoder does not produce stable passwords.
Long story short, the event handling code ends up thinking the password encryption method changed, and rewrites the config file.

Not a show stopper, but if one manages the gs configuration via version control, that will generate a local change which will result in conflicts at the next data dir update.

So I’m wondering, is it really necessary to trigger the post changed event in the init method?
As far as I can see there is nothing using it.

An alternative could be to provide the listener both the old and new config, and let them deduce that the event is an init one because there was no config previously

Opinions?

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

On Sun, Jul 7, 2013 at 10:18 AM, Christian Mueller <
christian.mueller@anonymised.com> wrote:

Hi Andrea

1) Our password encoders never produce the same result for identical plain
text passwords. The encoding uses a random salt.

2) The post changed event is used by GeoServerSecurityFilterChainProxy to
create the internal data structure for the filter chains.

3) What about checking the encrypted password
with GeoServerPasswordEncoder.isResponsibleForEncoding(..). If the current
config password encoder is responsible for the encrypted password, you can
skip the recode logic.

Yes, this approach crossed my mind. However... is it possible to have a
configurable password encoder, that would take parameters to run, and thus
with the same encoder, the password structure would be different? I'm
probably just thinking too much...

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

The password encoders are injected as Spring beans (applicationSecurityContext.xml). Here is an example






If you have encrypted passwords and you change the “algorithm” property, it is not possible to decrypt these passwords. I think this is the only way to break the encoding/decoding schema. I think most people will not be able to interpret the value and will not change it.

People having those skills should know what they are doing.

I would go on with "“isResponsibleForEncdoing”

Cheers

···

2013/7/7 Andrea Aime <andrea.aime@anonymised.com>

On Sun, Jul 7, 2013 at 10:18 AM, Christian Mueller <christian.mueller@anonymised.com.3674…> wrote:

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Andrea

  1. Our password encoders never produce the same result for identical plain text passwords. The encoding uses a random salt.

  2. The post changed event is used by GeoServerSecurityFilterChainProxy to create the internal data structure for the filter chains.

  3. What about checking the encrypted password with GeoServerPasswordEncoder.isResponsibleForEncoding(…). If the current config password encoder is responsible for the encrypted password, you can skip the recode logic.

Yes, this approach crossed my mind. However… is it possible to have a configurable password encoder, that would take parameters to run, and thus with the same encoder, the password structure would be different? I’m probably just thinking too much…

Cheers

Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it