RFC-18: Encryption of passwords in mapfiles

[Frank Warmerdam]

Daniel Morissette wrote:
> I have created RFC-18 that proposes a mechanism to encrypt database 
> connection information (mostly passwords) in mapfiles:
> 
>   http://mapserver.gis.umn.edu/development/rfc/ms-rfc-18
> 
> Other than trying to figure out how to use OpenSSL, this is a relatively 
> simple addition that shouldn't have much impact on MapServer.
> 
> Before we vote on this, I would be interested in feedback from the 
> various database connection maintainers since I want this to work for at 
> least PostGIS, Oracle Spatial, SDE and OGR.
> 
> Also, if anyone has experience with OpenSSL or pointers to sample code 
> that uses it to do a similar task then I would be very interested 
> (Unfortunately the OpenSSL documentation seems to be quite poor). I'm 
> also interested if you know of better/simpler alternatives that could be 
> used instead of OpenSSL for the encryption functions.

Daniel,

First, I am a bit concerned about the use of {} to mark encrypted passwords.
It may be hard to know whether they apppear in an OGR connection string as
part of a password or even some other part of the connection since OGR
connection strings can vary quite a bit for different drivers.   A "worst
case" example of this is the VRT mechanism where the entire VRT file can
be embedded in the connection string.   I don't have a good solution to
my concern though.

Second, it seems we are just needing a relatively simple encrypt/decrypt
capability and it seems like overkill to add a direct (though optional)
dependency on OpenSSL just for that.  Given short fragments being encrypted
(the passwords) I would think we don't need something super sophisticated.

Ideally, I would like to see us "adapt" some simple buffer encryption
code rather than depending on an external library - assuming we can find
some that is relatively small/simple.

Also, I think hex encoding instead of PEM encoding would be sufficient if
we didn't chose to use OpenSSL.

One encryption approach I implemented in the past can be seen at:
   http://www.pcigeomatics.com/cgi-bin/pcihlp/impcrypt

I'm not as confident in it as I was when I was younger, but I would
claim that short password strings are not going to be very vulnerable to
cracking even if the encryption method is a bit weak.

Skimming the net, the following would seem to be a relatively simple to
implement, yet well tested encryption algorithm.
   http://www.simonshepherd.supanet.com/tea.htm

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org