[Geoserver-devel] Making GWC play along with the password encryption game

GeoServer GeoServer Developer
1

Hi,

as you might now the latest GWC embedded in GeoServer allows to keep the disk quota subsystem in a relational database.
Part of the necessary information to connect to the db is username and password, which are stored using some GWC code based on XStream on disk.

Now, GWC has no notion of password encryption (with some good reason I’d say, since they only way to configure the stand-alone version is manual xml file editing), however it is bad that in GeoServer the same file has cleartext passwords when the rest of the system stores them encrypted.

So I was thinking, how about adding a PasswordEncoder interface to GeoWebCache that mimics, to a small extent, the GeoServer API?

interface org.geowebcache.security.PasswordEncoder {
// encrypt the value
String encode(String clearTextValue);

// check if the value has been encrypted by this encoder (GS uses prefixes to
// guess that afaik)
boolean isResponsibleFor(String encryptedValue);

// decodes the value, throws an exception if not encrypted by this encoder
String decode(String encryptedValue);
}

The idea is that in GWC we’d have one or more of these registered in the spring context, with a new config attribute marking one of them as the default one (and no password encoding happening if none is indicated) by bean name.

In GeoServer we’d have this configuration be locked onto a specific password encoder that is a bridge to the GeoServer own password encoding subsystem, which would delegate to ConfigurationPasswordEncryptionHelper to do the actual work.

Am I missing anything?
More in general, suggestions?

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

2

Hi Andrea

First, good idea, +1.

I never worked with GWC, so I hope my assumptions are correct here.

I think we need 3 methods

  1. String encode(String clearTextValue);
    Simply use ConfigurationPasswordEncryptionHelper.encode(…)

  2. String decode(String encryptedValue);

Simply use ConfigurationPasswordEncryptionHelper.decode(…)

  1. recodeAll
    Recodes all passwords used by GWC. Be aware of the fact that even plain text passwords
    have a prefix. (Your assumptions about the prefix are correct). The password

mypassword

is stored as

plain:mypassword.

Maybe we need some migration code.

I think the method isResponsibleFor is not necessary, except GWC uses its own encoders.

Let me know if I can assist further.

Christian

···

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

Hi,

as you might now the latest GWC embedded in GeoServer allows to keep the disk quota subsystem in a relational database.
Part of the necessary information to connect to the db is username and password, which are stored using some GWC code based on XStream on disk.

Now, GWC has no notion of password encryption (with some good reason I’d say, since they only way to configure the stand-alone version is manual xml file editing), however it is bad that in GeoServer the same file has cleartext passwords when the rest of the system stores them encrypted.

So I was thinking, how about adding a PasswordEncoder interface to GeoWebCache that mimics, to a small extent, the GeoServer API?

interface org.geowebcache.security.PasswordEncoder {
// encrypt the value
String encode(String clearTextValue);

// check if the value has been encrypted by this encoder (GS uses prefixes to
// guess that afaik)
boolean isResponsibleFor(String encryptedValue);

// decodes the value, throws an exception if not encrypted by this encoder
String decode(String encryptedValue);
}

The idea is that in GWC we’d have one or more of these registered in the spring context, with a new config attribute marking one of them as the default one (and no password encoding happening if none is indicated) by bean name.

In GeoServer we’d have this configuration be locked onto a specific password encoder that is a bridge to the GeoServer own password encoding subsystem, which would delegate to ConfigurationPasswordEncryptionHelper to do the actual work.

Am I missing anything?
More in general, suggestions?

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

3

On Sat, Jun 15, 2013 at 5:06 PM, Christian Mueller <
christian.mueller@anonymised.com> wrote:

Hi Andrea

First, good idea, +1.

I never worked with GWC, so I hope my assumptions are correct here.

I think we need 3 methods

1) String encode(String clearTextValue);
Simply use ConfigurationPasswordEncryptionHelper.encode(..)

2) String decode(String encryptedValue);
Simply use ConfigurationPasswordEncryptionHelper.decode(..)

3) recodeAll
Recodes all passwords used by GWC. Be aware of the fact that even plain
text passwords
have a prefix. (Your assumptions about the prefix are correct). The
password

mypassword

is stored as

plain:mypassword.

This one troubles me. As said, standalone GWC users are forced into editing
the configuration
files by hand, having to force this kind of change on them is going to be
nasty, and would
make little sense too since I don't see any standalone GWC user encrypting
passwords anyways.

For the embedded GWC, the only place where a password can reside that has a
GUI editor
is the disk quota database, so that's the only password that might have to
be rewritten.

This recodeAll method you're citing, does it have a GeoServer equivalent? I
guess it's done
on startup when figuring out the data dir has the old security system,
right?
In the embedded GWC case I'd have no such information, the only way to
figure out
passwords are not encoded is when reading the disk quota configuration, and
finding there
is no prefix, so I guess that's where the eventual re-coding should happen.
I should probably add a "encryptedPassword" field in the configuration, so
that the existing
field plays the role of the un-encrypted one and can be used to determine
whether the config
has been encrypted or not.

Maybe we need some migration code.

I think the method isResponsibleFor is not necessary, except GWC uses its
own encoders.

Maybe not indeed, I was considering a case in which the password encoder
changed... even if
I don't see normal standalone GWC users entering encrypted passwords in the
config files,
I was thinking about future-proofing the code, so that if GWC ever gets its
own config GUI,
we have a way to handle changing the password encryption.

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

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

4

On Tue, Jun 18, 2013 at 11:20 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

Maybe not indeed, I was considering a case in which the password encoder
changed... even if
I don't see normal standalone GWC users entering encrypted passwords in
the config files,
I was thinking about future-proofing the code, so that if GWC ever gets
its own config GUI,
we have a way to handle changing the password encryption.

I had another look at the whole matter and believe this can be solved
without having to modify
GWC at all.
GeoServer has two methods to load and save the JDBC configuration (used by
the GUI),
so I just need to tap into those and encrypt the password before it gets
saved, and decrypt
it on the way back, before GWC can start using it.

I cannot know if the password is encrypted or not just by searching for the
well
known prefixes, but I can just test with each GeoServer password encoder if
the value is something
it can handle, and if none is found, assume the password is still plaintext.
Might have some little glitch for some unlucky cases where the plaintext
password is matched
by some password encoder, but that should be very unlikely,
and the functionality is only a few months old, and only useful in
clustered environments,
so very few people are probably already using it.
Plus it has a simple fix, just go into the GUI and enter the right password
again

Would that be acceptable?

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

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

5

On Wed, Jun 19, 2013 at 11:52 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Tue, Jun 18, 2013 at 11:20 AM, Andrea Aime <
andrea.aime@anonymised.com> wrote:

Maybe not indeed, I was considering a case in which the password encoder
changed... even if
I don't see normal standalone GWC users entering encrypted passwords in
the config files,
I was thinking about future-proofing the code, so that if GWC ever gets
its own config GUI,
we have a way to handle changing the password encryption.

I had another look at the whole matter and believe this can be solved
without having to modify
GWC at all.
GeoServer has two methods to load and save the JDBC configuration (used by
the GUI),
so I just need to tap into those and encrypt the password before it gets
saved, and decrypt
it on the way back, before GWC can start using it.

I cannot know if the password is encrypted or not just by searching for
the well
known prefixes, but I can just test with each GeoServer password encoder
if the value is something
it can handle, and if none is found, assume the password is still
plaintext.
Might have some little glitch for some unlucky cases where the plaintext
password is matched
by some password encoder, but that should be very unlikely,
and the functionality is only a few months old, and only useful in
clustered environments,
so very few people are probably already using it.
Plus it has a simple fix, just go into the GUI and enter the right
password again

Would that be acceptable?

Cough cough... anyone? :slight_smile:

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

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

6

Hi Andrea

About checking plain text passwords.

Let us assume we have a plain text password like

crypt1:abc

In this case, a GeoServer password decoder will feel responsible for decoding. This is the unlucky situation because the encoder is not responsible.

Nevertheless, if you try to decrypt the password I am quite sure that you will get a runtime exception

org.jasypt.exceptions.EncryptionOperationNotPossibleException

This happens because the encrypted password has a format. There is a padding, a hex/base64 encoding, a random salt with a fixed length at a fixed position and whatsoever I cannot remember at the moment. (Depends on the encoder used).

If you get such an exception, the reason may be

  1. The password was a plain text password
  2. The password was already encrypted but tampered anywhere in the system

Unfortunately, you cannot decide and as a consequence, an “emergency exit” is needed like reentering the password on the GUI.

An example for a valid encrypted password is

crypt1:KWhO7jrTz/Gi0oTQRKsVeCmWIZY5VZaD

I cannot image a user having such a plain text password. It is easier to win the jack pot in a lottery than remember such a password :slight_smile:

As simple calculation. Let us assume that the password alphabet consists of 26 lower case letters,10 digits and the “:”. Then you have 37^7 = 94931877133 possibilities for the first 7 characters. Very unlikely that a password starts with “crypt1:”

Taking this numbers into account, +1 for your proposal, we should not make things more complicated as needed.

Cheers
Christian

···

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

On Wed, Jun 19, 2013 at 11:52 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

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

On Tue, Jun 18, 2013 at 11:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Cough cough… anyone? :slight_smile:

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

Maybe not indeed, I was considering a case in which the password encoder changed… even if

I had another look at the whole matter and believe this can be solved without having to modify
GWC at all.
GeoServer has two methods to load and save the JDBC configuration (used by the GUI),
so I just need to tap into those and encrypt the password before it gets saved, and decrypt
it on the way back, before GWC can start using it.

I cannot know if the password is encrypted or not just by searching for the well
known prefixes, but I can just test with each GeoServer password encoder if the value is something
it can handle, and if none is found, assume the password is still plaintext.
Might have some little glitch for some unlucky cases where the plaintext password is matched
by some password encoder, but that should be very unlikely,
and the functionality is only a few months old, and only useful in clustered environments,
so very few people are probably already using it.
Plus it has a simple fix, just go into the GUI and enter the right password again

Would that be acceptable?

I don’t see normal standalone GWC users entering encrypted passwords in the config files,
I was thinking about future-proofing the code, so that if GWC ever gets its own config GUI,
we have a way to handle changing the password encryption.

7

On Fri, Jun 21, 2013 at 2:32 PM, Christian Mueller <
christian.mueller@anonymised.com> wrote:

If you get such an exception, the reason may be

1) The password was a plain text password
2) The password was already encrypted but tampered anywhere in the system

Unfortunately, you cannot decide and as a consequence, an "emergency exit"
is needed like reentering the password on the GUI.

Yes, which is not big deal

An example for a valid encrypted password is

crypt1:KWhO7jrTz/Gi0oTQRKsVeCmWIZY5VZaD

I cannot image a user having such a plain text password. It is easier to
win the jack pot in a lottery than remember such a password :slight_smile:

Ha ha, yeah.

As simple calculation. Let us assume that the password alphabet consists
of 26 lower case letters,10 digits and the ":". Then you have 37^7
= 94931877133 possibilities for the first 7 characters. Very unlikely that
a password starts with "crypt1:"

Taking this numbers into account, +1 for your proposal, we should not make
things more complicated as needed.

Thanks for the reply and the detailed evaluation about what might go wrong.
Anyone else?

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

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