[Geoserver-devel] plaintext password storage

GeoServer GeoServer Developer
1

Hi everyone,

Geoserver currently stores user and datastore connection passwords in
plaintext. This is obviously a security issue.

I have opened http://jira.codehaus.org/browse/GEOS-4702 to address
this. As Andrea noted, this needs to be discussed and digested (hehe,
sorry) a bit.

A quick overview of the goals of this issue/patch:

1) Enable password digesting for users.properties. Digesting is
one-way encryption and does not support recovery. This needs to
integrate with the existing spring security and should not effect any
external use. Existing users' passwords will be digested automagically
and new passwords handled without any changes to user interface.
2) Enable two-way encryption of datastore passwords (the passwords
often need to be provided in plaintext to the external
service/system). The upgrade should occur automagically without any
changes to the credential users. A default, low-level security option
should be provided with configurable options as well as a path to a
custom provider replacement.
3) Support (or at least have a path to) 1 and 2 for whatever new
subsystems come along that require this service.

Here is a list of discussion items:

1. The current patch adds a new dependency - jasypt
(http://www.jasypt.org/). Weighing in at a 169K, this library wraps
the core security libraries and provides spring integration (and
more). Christian's work (see 7 below) may also be using this. It may
be possible that the 'lite' version of this library could suffice.
Alternatively, the wrapper functionality and spring integration could
be replaced. I am partial to reuse myself.
2. Upgrade path - Currently, the patch will upgrade automagically and
attempt to every time. This is not a big hit for a small number of
users/storeinfos, but could be for larger numbers (e.g. lots of
shapefiles/tiffs). This is because all storeinfos need to be scanned
to detect passwords and the code for this is somewhat inefficient.
This relates to http://jira.codehaus.org/browse/GEOS-4701. An
alternative could be to refactor the upgrade code somehow to be more
efficient.
3. Release schedule (fix for version) - up in the air.
4. Default master password - currently, the default master password is
in code. An (better) alternative would be to add it to the global
configuration and generate a random one. This could potentially be a
replacement for GEOS-4701 (presence of property, blank or otherwise,
in config marks the upgrade) though I still think that the latter is
warranted.
5. Other master password options - the master password has to come
from somewhere. The earlier issue and patch
(http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore
with optional password. The password, if present, would have to be
provided (of course). The 'advanced' (marginally more secure than
default password) option that is provided with the new patch is to
allow provisioning by servlet context param (more hidden than being in
global), system property, or environment variable (same). Jasypt also
supports a boot-strapping feature
(http://www.jasypt.org/webconfiguration.html) that would require more
work. A security minded user could also create a custom provider (get
the password from some other location or deliberately obfuscated code)
that would not use the above approaches. No solution will be
completely fool proof due to the problem space, but the current state
of plaintext passwords is bad - separating the master password from
the encrypted passwords is a major step up.
6. Alternative password store - the provider could even be a delegate
to external storage and retrieval of storeinfo passwords.
7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian's
scope of work does not currently appear to address the storeinfo
issue. My intention when I started this work was to not diminish,
replace, or duplicate his efforts and I see them as fully compatible
in intention if not implementation.

Missing functionality and other issues:
1. Conversion tool - if the master password changes, the storeinfo
passwords will require re-encryption.
2. Documentation on configuration options. This includes digest
options (and implications) and master password configuration.
3. API/SPI improvement and doc

Any and all discussion welcome.

Thanks,
--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

On Mon, Aug 8, 2011 at 9:09 PM, Ian Schneider <ischneider@anonymised.com> wrote:

Hi everyone,

Geoserver currently stores user and datastore connection passwords in
plaintext. This is obviously a security issue.

I have opened http://jira.codehaus.org/browse/GEOS-4702 to address
this. As Andrea noted, this needs to be discussed and digested (hehe,
sorry) a bit.

Hmm... c'mon people, don't push, comment one at a time!
Sigh, August, everybody is having his/her vacation I guess :-p

A quick overview of the goals of this issue/patch:

1) Enable password digesting for users.properties. Digesting is
one-way encryption and does not support recovery. This needs to
integrate with the existing spring security and should not effect any
external use. Existing users' passwords will be digested automagically
and new passwords handled without any changes to user interface.

What if a user password is edited, then saved, then open again,
the save again. Is the password going to be preserved?
Put another way, what do you store in the password fields in the GUI?
Once it's digested you should not be re-digest the contents of the
field unless it's changed.

2) Enable two-way encryption of datastore passwords (the passwords
often need to be provided in plaintext to the external
service/system). The upgrade should occur automagically without any
changes to the credential users. A default, low-level security option
should be provided with configurable options as well as a path to a
custom provider replacement.

+1

3) Support (or at least have a path to) 1 and 2 for whatever new
subsystems come along that require this service.

Here is a list of discussion items:

1. The current patch adds a new dependency - jasypt
(http://www.jasypt.org/). Weighing in at a 169K, this library wraps
the core security libraries and provides spring integration (and
more). Christian's work (see 7 below) may also be using this. It may
be possible that the 'lite' version of this library could suffice.
Alternatively, the wrapper functionality and spring integration could
be replaced. I am partial to reuse myself.

No comment on this one, but I hope Christian will chime in as his
code is affected. Afaik he wanted to use whatever Spring offers.

2. Upgrade path - Currently, the patch will upgrade automagically and
attempt to every time. This is not a big hit for a small number of
users/storeinfos, but could be for larger numbers (e.g. lots of
shapefiles/tiffs). This is because all storeinfos need to be scanned
to detect passwords and the code for this is somewhat inefficient.
This relates to http://jira.codehaus.org/browse/GEOS-4701. An
alternative could be to refactor the upgrade code somehow to be more
efficient.

The approach works for me

3. Release schedule (fix for version) - up in the air.

This is an important detail though. This work is probably warranting a GSIP,
but if you want to commit on 2.1.x it most definitely needs one.

4. Default master password - currently, the default master password is
in code. An (better) alternative would be to add it to the global
configuration and generate a random one. This could potentially be a
replacement for GEOS-4701 (presence of property, blank or otherwise,
in config marks the upgrade) though I still think that the latter is
warranted.

Mumble mumble... can't make up my mind on this one. Let's move on :slight_smile:

5. Other master password options - the master password has to come
from somewhere. The earlier issue and patch
(http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore
with optional password. The password, if present, would have to be
provided (of course). The 'advanced' (marginally more secure than
default password) option that is provided with the new patch is to
allow provisioning by servlet context param (more hidden than being in
global), system property, or environment variable (same). Jasypt also
supports a boot-strapping feature
(http://www.jasypt.org/webconfiguration.html) that would require more
work. A security minded user could also create a custom provider (get
the password from some other location or deliberately obfuscated code)
that would not use the above approaches. No solution will be
completely fool proof due to the problem space, but the current state
of plaintext passwords is bad - separating the master password from
the encrypted passwords is a major step up.

I would see positively some sort of plugin allowing to provide the
master password. With the default implementation of it just using
a constant value.

6. Alternative password store - the provider could even be a delegate
to external storage and retrieval of storeinfo passwords.

Ah, storing just keys in the stores that would be used to lookup
in the password store? Interesting indeed.
Could be made a plugin again. Not sure how important this is though,
I would be curious to hear from people playing with authorization
more than me.

7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian's
scope of work does not currently appear to address the storeinfo
issue. My intention when I started this work was to not diminish,
replace, or duplicate his efforts and I see them as fully compatible
in intention if not implementation.

Hoping that Christian will chime in soon :slight_smile:

Missing functionality and other issues:
1. Conversion tool - if the master password changes, the storeinfo
passwords will require re-encryption.

This seems like a pretty big item.
If I know the users they tend to consider security 5 minutes before
going live, you decide to change the master password and boom,
you have to reconfigure all users and stores. Ouch!

2. Documentation on configuration options. This includes digest
options (and implications) and master password configuration.

This is actually needed

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

3

Thanks for taking the time to chime in, Andrea. Comments inline where
I have one at the moment.

1) Enable password digesting for users.properties. Digesting is
one-way encryption and does not support recovery. This needs to
integrate with the existing spring security and should not effect any
external use. Existing users' passwords will be digested automagically
and new passwords handled without any changes to user interface.

What if a user password is edited, then saved, then open again,
the save again. Is the password going to be preserved?
Put another way, what do you store in the password fields in the GUI?
Once it's digested you should not be re-digest the contents of the
field unless it's changed.

Good question. The digested passwords (user only) are surrounded by a
prefix and suffix (note to self that UI needs to prevent use of prefix
and suffix!). What goes into the fields is the digested value. The DAO
will not re-digest passwords that contain this prefix and suffix. I
added a UI test to verify this (not included in patch yet)

3. Release schedule (fix for version) - up in the air.

This is an important detail though. This work is probably warranting a GSIP,
but if you want to commit on 2.1.x it most definitely needs one.

Sounds fair. I'll let others give a vote of confidence or otherwise
before I get started.

6. Alternative password store - the provider could even be a delegate
to external storage and retrieval of storeinfo passwords.

Ah, storing just keys in the stores that would be used to lookup
in the password store? Interesting indeed.
Could be made a plugin again. Not sure how important this is though,
I would be curious to hear from people playing with authorization
more than me.

There is not much more true security here, but perhaps more
obfuscation. A keystore can have a password or not. If it does, the
password still needs to be stored somewhere and provided to the app at
runtime.

Missing functionality and other issues:
1. Conversion tool - if the master password changes, the storeinfo
passwords will require re-encryption.

This seems like a pretty big item.
If I know the users they tend to consider security 5 minutes before
going live, you decide to change the master password and boom,
you have to reconfigure all users and stores. Ouch!

Indeed an important item, though not terribly complicated.

2. Documentation on configuration options. This includes digest
options (and implications) and master password configuration.

This is actually needed

Yes.

--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

Hi Ian; we have hit this issue internally as well. Mark was directing us towards the use of bcrypt. I will let him know about this email thread and ask him to share his thoughts here.

Jody

On Tue, Aug 9, 2011 at 5:09 AM, Ian Schneider <ischneider@anonymised.com> wrote:

Hi everyone,

Geoserver currently stores user and datastore connection passwords in
plaintext. This is obviously a security issue.

I have opened http://jira.codehaus.org/browse/GEOS-4702 to address
this. As Andrea noted, this needs to be discussed and digested (hehe,
sorry) a bit.

A quick overview of the goals of this issue/patch:

  1. Enable password digesting for users.properties. Digesting is
    one-way encryption and does not support recovery. This needs to
    integrate with the existing spring security and should not effect any
    external use. Existing users’ passwords will be digested automagically
    and new passwords handled without any changes to user interface.
  2. Enable two-way encryption of datastore passwords (the passwords
    often need to be provided in plaintext to the external
    service/system). The upgrade should occur automagically without any
    changes to the credential users. A default, low-level security option
    should be provided with configurable options as well as a path to a
    custom provider replacement.
  3. Support (or at least have a path to) 1 and 2 for whatever new
    subsystems come along that require this service.

Here is a list of discussion items:

  1. The current patch adds a new dependency - jasypt
    (http://www.jasypt.org/). Weighing in at a 169K, this library wraps
    the core security libraries and provides spring integration (and
    more). Christian’s work (see 7 below) may also be using this. It may
    be possible that the ‘lite’ version of this library could suffice.
    Alternatively, the wrapper functionality and spring integration could
    be replaced. I am partial to reuse myself.
  2. Upgrade path - Currently, the patch will upgrade automagically and
    attempt to every time. This is not a big hit for a small number of
    users/storeinfos, but could be for larger numbers (e.g. lots of
    shapefiles/tiffs). This is because all storeinfos need to be scanned
    to detect passwords and the code for this is somewhat inefficient.
    This relates to http://jira.codehaus.org/browse/GEOS-4701. An
    alternative could be to refactor the upgrade code somehow to be more
    efficient.
  3. Release schedule (fix for version) - up in the air.
  4. Default master password - currently, the default master password is
    in code. An (better) alternative would be to add it to the global
    configuration and generate a random one. This could potentially be a
    replacement for GEOS-4701 (presence of property, blank or otherwise,
    in config marks the upgrade) though I still think that the latter is
    warranted.
  5. Other master password options - the master password has to come
    from somewhere. The earlier issue and patch
    (http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore
    with optional password. The password, if present, would have to be
    provided (of course). The ‘advanced’ (marginally more secure than
    default password) option that is provided with the new patch is to
    allow provisioning by servlet context param (more hidden than being in
    global), system property, or environment variable (same). Jasypt also
    supports a boot-strapping feature
    (http://www.jasypt.org/webconfiguration.html) that would require more
    work. A security minded user could also create a custom provider (get
    the password from some other location or deliberately obfuscated code)
    that would not use the above approaches. No solution will be
    completely fool proof due to the problem space, but the current state
    of plaintext passwords is bad - separating the master password from
    the encrypted passwords is a major step up.
  6. Alternative password store - the provider could even be a delegate
    to external storage and retrieval of storeinfo passwords.
  7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian’s
    scope of work does not currently appear to address the storeinfo
    issue. My intention when I started this work was to not diminish,
    replace, or duplicate his efforts and I see them as fully compatible
    in intention if not implementation.

Missing functionality and other issues:

  1. Conversion tool - if the master password changes, the storeinfo
    passwords will require re-encryption.
  2. Documentation on configuration options. This includes digest
    options (and implications) and master password configuration.
  3. API/SPI improvement and doc

Any and all discussion welcome.

Thanks,

Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1

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

5

Hi Jody,

Whatever mechanism is finally in place should allow for extension.
That is, if the default digest algorithm or provider is not
sufficient, it should be replaceable.

BCrypt is just an algorithm and there is no implementation (provider)
in the SDK. BCrypt also incurs significant overhead with the benefit
of more secure passwords. The current situation is no security, so I'd
like to get this moving ASAP.

Thanks,
-Ian

On Tue, Aug 9, 2011 at 8:43 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Ian; we have hit this issue internally as well. Mark was directing us
towards the use of bcrypt. I will let him know about this email thread and
ask him to share his thoughts here.
Jody

On Tue, Aug 9, 2011 at 5:09 AM, Ian Schneider <ischneider@anonymised.com>
wrote:

Hi everyone,

Geoserver currently stores user and datastore connection passwords in
plaintext. This is obviously a security issue.

I have opened http://jira.codehaus.org/browse/GEOS-4702 to address
this. As Andrea noted, this needs to be discussed and digested (hehe,
sorry) a bit.

A quick overview of the goals of this issue/patch:

1) Enable password digesting for users.properties. Digesting is
one-way encryption and does not support recovery. This needs to
integrate with the existing spring security and should not effect any
external use. Existing users' passwords will be digested automagically
and new passwords handled without any changes to user interface.
2) Enable two-way encryption of datastore passwords (the passwords
often need to be provided in plaintext to the external
service/system). The upgrade should occur automagically without any
changes to the credential users. A default, low-level security option
should be provided with configurable options as well as a path to a
custom provider replacement.
3) Support (or at least have a path to) 1 and 2 for whatever new
subsystems come along that require this service.

Here is a list of discussion items:

1. The current patch adds a new dependency - jasypt
(http://www.jasypt.org/). Weighing in at a 169K, this library wraps
the core security libraries and provides spring integration (and
more). Christian's work (see 7 below) may also be using this. It may
be possible that the 'lite' version of this library could suffice.
Alternatively, the wrapper functionality and spring integration could
be replaced. I am partial to reuse myself.
2. Upgrade path - Currently, the patch will upgrade automagically and
attempt to every time. This is not a big hit for a small number of
users/storeinfos, but could be for larger numbers (e.g. lots of
shapefiles/tiffs). This is because all storeinfos need to be scanned
to detect passwords and the code for this is somewhat inefficient.
This relates to http://jira.codehaus.org/browse/GEOS-4701. An
alternative could be to refactor the upgrade code somehow to be more
efficient.
3. Release schedule (fix for version) - up in the air.
4. Default master password - currently, the default master password is
in code. An (better) alternative would be to add it to the global
configuration and generate a random one. This could potentially be a
replacement for GEOS-4701 (presence of property, blank or otherwise,
in config marks the upgrade) though I still think that the latter is
warranted.
5. Other master password options - the master password has to come
from somewhere. The earlier issue and patch
(http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore
with optional password. The password, if present, would have to be
provided (of course). The 'advanced' (marginally more secure than
default password) option that is provided with the new patch is to
allow provisioning by servlet context param (more hidden than being in
global), system property, or environment variable (same). Jasypt also
supports a boot-strapping feature
(http://www.jasypt.org/webconfiguration.html) that would require more
work. A security minded user could also create a custom provider (get
the password from some other location or deliberately obfuscated code)
that would not use the above approaches. No solution will be
completely fool proof due to the problem space, but the current state
of plaintext passwords is bad - separating the master password from
the encrypted passwords is a major step up.
6. Alternative password store - the provider could even be a delegate
to external storage and retrieval of storeinfo passwords.
7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian's
scope of work does not currently appear to address the storeinfo
issue. My intention when I started this work was to not diminish,
replace, or duplicate his efforts and I see them as fully compatible
in intention if not implementation.

Missing functionality and other issues:
1. Conversion tool - if the master password changes, the storeinfo
passwords will require re-encryption.
2. Documentation on configuration options. This includes digest
options (and implications) and master password configuration.
3. API/SPI improvement and doc

Any and all discussion welcome.

Thanks,
--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

Perfectly understood; my real comment was that I would ask Mark to join the conversation (and that there may be room for collaboration).

–
Jody Garnett

On Saturday, 13 August 2011 at 8:53 AM, Ian Schneider wrote:

Hi Jody,

Whatever mechanism is finally in place should allow for extension.
That is, if the default digest algorithm or provider is not
sufficient, it should be replaceable.

BCrypt is just an algorithm and there is no implementation (provider)
in the SDK. BCrypt also incurs significant overhead with the benefit
of more secure passwords. The current situation is no security, so I’d
like to get this moving ASAP.

Thanks,
-Ian

On Tue, Aug 9, 2011 at 8:43 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Ian; we have hit this issue internally as well. Mark was directing us
towards the use of bcrypt. I will let him know about this email thread and
ask him to share his thoughts here.
Jody

On Tue, Aug 9, 2011 at 5:09 AM, Ian Schneider <ischneider@anonymised.com>
wrote:

Hi everyone,

Geoserver currently stores user and datastore connection passwords in
plaintext. This is obviously a security issue.

I have opened http://jira.codehaus.org/browse/GEOS-4702 to address
this. As Andrea noted, this needs to be discussed and digested (hehe,
sorry) a bit.

A quick overview of the goals of this issue/patch:

  1. Enable password digesting for users.properties. Digesting is
    one-way encryption and does not support recovery. This needs to
    integrate with the existing spring security and should not effect any
    external use. Existing users’ passwords will be digested automagically
    and new passwords handled without any changes to user interface.
  2. Enable two-way encryption of datastore passwords (the passwords
    often need to be provided in plaintext to the external
    service/system). The upgrade should occur automagically without any
    changes to the credential users. A default, low-level security option
    should be provided with configurable options as well as a path to a
    custom provider replacement.
  3. Support (or at least have a path to) 1 and 2 for whatever new
    subsystems come along that require this service.

Here is a list of discussion items:

  1. The current patch adds a new dependency - jasypt
    (http://www.jasypt.org/). Weighing in at a 169K, this library wraps
    the core security libraries and provides spring integration (and
    more). Christian’s work (see 7 below) may also be using this. It may
    be possible that the ‘lite’ version of this library could suffice.
    Alternatively, the wrapper functionality and spring integration could
    be replaced. I am partial to reuse myself.
  2. Upgrade path - Currently, the patch will upgrade automagically and
    attempt to every time. This is not a big hit for a small number of
    users/storeinfos, but could be for larger numbers (e.g. lots of
    shapefiles/tiffs). This is because all storeinfos need to be scanned
    to detect passwords and the code for this is somewhat inefficient.
    This relates to http://jira.codehaus.org/browse/GEOS-4701. An
    alternative could be to refactor the upgrade code somehow to be more
    efficient.
  3. Release schedule (fix for version) - up in the air.
  4. Default master password - currently, the default master password is
    in code. An (better) alternative would be to add it to the global
    configuration and generate a random one. This could potentially be a
    replacement for GEOS-4701 (presence of property, blank or otherwise,
    in config marks the upgrade) though I still think that the latter is
    warranted.
  5. Other master password options - the master password has to come
    from somewhere. The earlier issue and patch
    (http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore
    with optional password. The password, if present, would have to be
    provided (of course). The ‘advanced’ (marginally more secure than
    default password) option that is provided with the new patch is to
    allow provisioning by servlet context param (more hidden than being in
    global), system property, or environment variable (same). Jasypt also
    supports a boot-strapping feature
    (http://www.jasypt.org/webconfiguration.html) that would require more
    work. A security minded user could also create a custom provider (get
    the password from some other location or deliberately obfuscated code)
    that would not use the above approaches. No solution will be
    completely fool proof due to the problem space, but the current state
    of plaintext passwords is bad - separating the master password from
    the encrypted passwords is a major step up.
  6. Alternative password store - the provider could even be a delegate
    to external storage and retrieval of storeinfo passwords.
  7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian’s
    scope of work does not currently appear to address the storeinfo
    issue. My intention when I started this work was to not diminish,
    replace, or duplicate his efforts and I see them as fully compatible
    in intention if not implementation.

Missing functionality and other issues:

  1. Conversion tool - if the master password changes, the storeinfo
    passwords will require re-encryption.
  2. Documentation on configuration options. This includes digest
    options (and implications) and master password configuration.
  3. API/SPI improvement and doc

Any and all discussion welcome.

Thanks,

Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1

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

–
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

7

I agree that any solution should be extendible to allow eventual users
to select their own balance of speed vs security.
I'm also happy to see the user guide section has been added, and is
straight-forward enough to be understood.

--
Mark

On 13 August 2011 12:47, Jody Garnett <jody.garnett@anonymised.com> wrote:

Perfectly understood; my real comment was that I would ask Mark to join the
conversation (and that there may be room for collaboration).
--
Jody Garnett

On Saturday, 13 August 2011 at 8:53 AM, Ian Schneider wrote:

Hi Jody,

Whatever mechanism is finally in place should allow for extension.
That is, if the default digest algorithm or provider is not
sufficient, it should be replaceable.

BCrypt is just an algorithm and there is no implementation (provider)
in the SDK. BCrypt also incurs significant overhead with the benefit
of more secure passwords. The current situation is no security, so I'd
like to get this moving ASAP.

Thanks,
-Ian

On Tue, Aug 9, 2011 at 8:43 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Ian; we have hit this issue internally as well. Mark was directing us
towards the use of bcrypt. I will let him know about this email thread and
ask him to share his thoughts here.
Jody

On Tue, Aug 9, 2011 at 5:09 AM, Ian Schneider <ischneider@anonymised.com>
wrote:

Hi everyone,

Geoserver currently stores user and datastore connection passwords in
plaintext. This is obviously a security issue.

I have opened http://jira.codehaus.org/browse/GEOS-4702 to address
this. As Andrea noted, this needs to be discussed and digested (hehe,
sorry) a bit.

A quick overview of the goals of this issue/patch:

1) Enable password digesting for users.properties. Digesting is
one-way encryption and does not support recovery. This needs to
integrate with the existing spring security and should not effect any
external use. Existing users' passwords will be digested automagically
and new passwords handled without any changes to user interface.
2) Enable two-way encryption of datastore passwords (the passwords
often need to be provided in plaintext to the external
service/system). The upgrade should occur automagically without any
changes to the credential users. A default, low-level security option
should be provided with configurable options as well as a path to a
custom provider replacement.
3) Support (or at least have a path to) 1 and 2 for whatever new
subsystems come along that require this service.

Here is a list of discussion items:

1. The current patch adds a new dependency - jasypt
(http://www.jasypt.org/). Weighing in at a 169K, this library wraps
the core security libraries and provides spring integration (and
more). Christian's work (see 7 below) may also be using this. It may
be possible that the 'lite' version of this library could suffice.
Alternatively, the wrapper functionality and spring integration could
be replaced. I am partial to reuse myself.
2. Upgrade path - Currently, the patch will upgrade automagically and
attempt to every time. This is not a big hit for a small number of
users/storeinfos, but could be for larger numbers (e.g. lots of
shapefiles/tiffs). This is because all storeinfos need to be scanned
to detect passwords and the code for this is somewhat inefficient.
This relates to http://jira.codehaus.org/browse/GEOS-4701. An
alternative could be to refactor the upgrade code somehow to be more
efficient.
3. Release schedule (fix for version) - up in the air.
4. Default master password - currently, the default master password is
in code. An (better) alternative would be to add it to the global
configuration and generate a random one. This could potentially be a
replacement for GEOS-4701 (presence of property, blank or otherwise,
in config marks the upgrade) though I still think that the latter is
warranted.
5. Other master password options - the master password has to come
from somewhere. The earlier issue and patch
(http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore
with optional password. The password, if present, would have to be
provided (of course). The 'advanced' (marginally more secure than
default password) option that is provided with the new patch is to
allow provisioning by servlet context param (more hidden than being in
global), system property, or environment variable (same). Jasypt also
supports a boot-strapping feature
(http://www.jasypt.org/webconfiguration.html) that would require more
work. A security minded user could also create a custom provider (get
the password from some other location or deliberately obfuscated code)
that would not use the above approaches. No solution will be
completely fool proof due to the problem space, but the current state
of plaintext passwords is bad - separating the master password from
the encrypted passwords is a major step up.
6. Alternative password store - the provider could even be a delegate
to external storage and retrieval of storeinfo passwords.
7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian's
scope of work does not currently appear to address the storeinfo
issue. My intention when I started this work was to not diminish,
replace, or duplicate his efforts and I see them as fully compatible
in intention if not implementation.

Missing functionality and other issues:
1. Conversion tool - if the master password changes, the storeinfo
passwords will require re-encryption.
2. Documentation on configuration options. This includes digest
options (and implications) and master password configuration.
3. API/SPI improvement and doc

Any and all discussion welcome.

Thanks,
--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy
to use, easy to manage, easy to install, easy to extend.
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com

8

3. Release schedule (fix for version) - up in the air.

This is an important detail though. This work is probably warranting a GSIP,
but if you want to commit on 2.1.x it most definitely needs one.

GSIP 63 under discussion.

http://geoserver.org/display/GEOS/GSIP+63+-+Encrypt+Plaintext+Passwords

9

Great work on this Ian. A very very welcome change. +1 on the proposal (just updated with my vote). And a few comments.

Regarding the testing… the way you did this is clever :slight_smile: I think it is fine for now since it is constrained to a single test class. However if this pattern pops up again I think it might be worth looking at an alternative like parameterized tests with junit 4 [1].

Also regarding where this work should take place. Is the intent to commit this on 2.1.x or not? Often when a significant change like this is implemented first we apply it to the trunk only, and this gives the change a bit of extra testing among devs who are using the trunk. Usually if there are major unforeseen issues they are flushed out within a week or so, making the backport to 2.1.x smoother. Might be wise to do do that here as well.

-Justin

[1] http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html

On Wed, Aug 17, 2011 at 4:48 PM, Ian Schneider <ischneider@anonymised.com> wrote:

  1. Release schedule (fix for version) - up in the air.

This is an important detail though. This work is probably warranting a GSIP,
but if you want to commit on 2.1.x it most definitely needs one.

GSIP 63 under discussion.

http://geoserver.org/display/GEOS/GSIP+63±+Encrypt+Plaintext+Passwords

Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take

the hassle out of deploying and managing Subversion and the

tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

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

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

10

Since this proposal changes the representation used to store datastore configurations, will it affect the REST API?

–
David Winslow
OpenGeo - http://opengeo.org/

On Thu, Aug 18, 2011 at 9:02 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Great work on this Ian. A very very welcome change. +1 on the proposal (just updated with my vote). And a few comments.

Regarding the testing… the way you did this is clever :slight_smile: I think it is fine for now since it is constrained to a single test class. However if this pattern pops up again I think it might be worth looking at an alternative like parameterized tests with junit 4 [1].

Also regarding where this work should take place. Is the intent to commit this on 2.1.x or not? Often when a significant change like this is implemented first we apply it to the trunk only, and this gives the change a bit of extra testing among devs who are using the trunk. Usually if there are major unforeseen issues they are flushed out within a week or so, making the backport to 2.1.x smoother. Might be wise to do do that here as well.

-Justin

[1] http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html

On Wed, Aug 17, 2011 at 4:48 PM, Ian Schneider <ischneider@anonymised.com> wrote:

  1. Release schedule (fix for version) - up in the air.

This is an important detail though. This work is probably warranting a GSIP,
but if you want to commit on 2.1.x it most definitely needs one.

GSIP 63 under discussion.

http://geoserver.org/display/GEOS/GSIP+63±+Encrypt+Plaintext+Passwords

Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take

the hassle out of deploying and managing Subversion and the

tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

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

–
Justin Deoliveira

OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

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

11

David,

The REST API should not be affected. As you note, the encryption only
affects the storage representation. The datastore passwords are
encrypted on write and decrypted on read via the XStreamPersister.
Therefore any code that uses the Catalog or XStreamPersister directly
will require no changes.

Nor will it will not affect REST API clients as authentication uses
the same subsystem as web ui, just a different approach to verifying
password.

I POSTED to a local instance and verified this behavior.

There is currently no test in the REST Config module to verify this,
but there is no test to verify that a JDBC data store that accepts a
passwd parameter is successful either.

-Ian

On Thu, Aug 18, 2011 at 7:12 AM, David Winslow <dwinslow@anonymised.com> wrote:

Since this proposal changes the representation used to store datastore
configurations, will it affect the REST API?

12

On Thu, Aug 18, 2011 at 12:48 AM, Ian Schneider <ischneider@anonymised.com> wrote:

3. Release schedule (fix for version) - up in the air.

This is an important detail though. This work is probably warranting a GSIP,
but if you want to commit on 2.1.x it most definitely needs one.

GSIP 63 under discussion.

http://geoserver.org/display/GEOS/GSIP+63+-+Encrypt+Plaintext+Passwords

Read the proposal, looks good, I did not take the time to review the patch
(in a hospital bed waiting for surgery, did not exactly feel like
reviewing a patch
today).

Sorry to perster about REST, but I too have a question.
Say I enable encrypted passwords, what do I get back from restconfig
for that store?
The rest subsystem indeed uses the xstream persister, with some customizations
to replace ids with atom links.

Another question is, say I need to add a new store, or change the password of
an existing store.
The rest client won't know how to encrypt the passwords, so it will post them
plain text... what will happen?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

13

Hi Andrea,

Read the proposal, looks good, I did not take the time to review the patch
(in a hospital bed waiting for surgery, did not exactly feel like
reviewing a patch
today).

Understandable. Hope things go well. Read the patch for extra sedation :wink:

Sorry to perster about REST, but I too have a question.

No problem, good questions.

Say I enable encrypted passwords, what do I get back from restconfig
for that store?

As it currently is implemented, the encrypted password is returned for
both xml and json formats. The html format does not contain the
parameters.

Another question is, say I need to add a new store, or change the password of
an existing store.
The rest client won't know how to encrypt the passwords, so it will post them
plain text... what will happen?

The StoreInfo receives the plaintext password and is written using the
persister. The persister encrypts the password to disk, but the
StoreInfo retains the plaintext password for use in connecting.

Your question was thought provoking and helped me prevent a bug. A
client that PUTs the encrypted password back will corrupt the password
since it will be re-encrypted. This is fixed in my local code now, but
with one little oddity - the persister will write out the encrypted
password but decrypt it for the StoreInfo. This doesn't seem like
appropriate persister behavior and it probably belongs in the catalog.
Thoughts?

Cheers
Andrea

Cheers to you - hope that tendon heals well.

--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

14

Hi Ian,
just added my plus one on the wiki page. Btw, the list of PSC members
is rather old, use a recent GSIP to get an up to date one.

Your question was thought provoking and helped me prevent a bug. A
client that PUTs the encrypted password back will corrupt the password
since it will be re-encrypted.

So rest clients will see the pwd as encrypted when doing get operations?

This is fixed in my local code now, but
with one little oddity - the persister will write out the encrypted
password but decrypt it for the StoreInfo. This doesn't seem like
appropriate persister behavior and it probably belongs in the catalog.
Thoughts?

Don't have a good idea here. If we keep the pwd encrypted in the catalog,
and decrypt them only when connecting to the store, we are going to have
troubles with the GUI, that needs the unencrypted as well

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

15

Hi Andrea,

On Fri, Aug 19, 2011 at 7:57 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi Ian,
just added my plus one on the wiki page. Btw, the list of PSC members
is rather old, use a recent GSIP to get an up to date one.

Thanks, will do.

Your question was thought provoking and helped me prevent a bug. A
client that PUTs the encrypted password back will corrupt the password
since it will be re-encrypted.

So rest clients will see the pwd as encrypted when doing get operations?

At the moment, that is the behavior.

This is fixed in my local code now, but
with one little oddity - the persister will write out the encrypted
password but decrypt it for the StoreInfo. This doesn't seem like
appropriate persister behavior and it probably belongs in the catalog.
Thoughts?

Don't have a good idea here. If we keep the pwd encrypted in the catalog,
and decrypt them only when connecting to the store, we are going to have
troubles with the GUI, that needs the unencrypted as well

I thought about this idea early on, but it seemed to spread the
responsibility of knowing about passwords' encryption state all around
the code. The way it is now is transparent to other parts of the code
(except tests).

Thanks,
-Ian

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

16

[sending to correct list this time]

On Fri, Aug 19, 2011 at 7:57 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi Ian,
just added my plus one on the wiki page. Btw, the list of PSC members
is rather old, use a recent GSIP to get an up to date one.

And the list of voters short :wink:

Are there any objections to this proposal?

If you haven't looked already, PSCs, please review and let me know if
you have any questions.

Thanks,
-Ian