RFC-18: Encryption of passwords in mapfiles

[Daniel Morissette]

Thanks for the feedback. I have updated MS-RFC-18 to:

- Use TEA for encryption/decryption instead of OpenSSL
- Use hex encoding instead of PEM (base64)
- Added a note about looking for pairs of { + } with just hex encoding 
chars in between
- Added a question about whether we should use a new ENCRYPTION_KEY 
keyword in the mapfile instead of CONFIG MS_ENCRYPTION_KEY (this came up 
on IRC)

Daniel


Frank Warmerdam wrote:
> Daniel Morissette wrote:
> 
>> Do you see this as a blocker issue?
> 
> 
> Daniel,
> 
> Not necessarily.
> 
>> 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?
> 
> 
> I think this would be a great idea.
> 
>> 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.
> 
> 
> Right.  I think it is much preferrable to just apply it to the password.
> 
>> 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/.
> 
> 
> I can't imagine efficiency is very important in this context.  And a more
> limited grammar of characters might make the validation described above
> safer.
> 
> Best regards,


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