RFC-18: Encryption of passwords in mapfiles

[Daniel Morissette]

Frank Warmerdam wrote:
> 
> 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.
> 

Do you see this as a blocker issue?

Perhaps the msDecryptString() function could look for a pair of { + }, 
and then verify that all chars in the block are valid base 64 encoding 
chars before proceeding with decryption. That should significantly 
reduce the chances of a false match. What do you think?

Another alternative would be to only allow encrypting the full 
connection string in one chunk, but it would be harder to maintain 
mapfiles this way.


> 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.
> 

Agreed, that's why I had written that I am very open to alternatives.

I like the Tiny Encryption Algorithm (TEA) that you found at 
http://www.simonshepherd.supanet.com/tea.htm. If I don't get other 
comments on that topic then I will update the RFC to use TEA.

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

I liked PEM (base 64) encoding because it is apparently the most compact 
way to encode binary data using printable chars. It increases the data 
size by a ratio of 4:3 instead of 2:1 for hex encoding. I had also found 
an implementation covered by a MIT license at 
http://base64.sourceforge.net/.

Since we're dealing with relatively short strings, I guess hex encoding 
would be enough and would save us from embedding more external code in 
MapServer. What do others think?

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/