Encrypt sensitive connector properties like passwords

[rbeckman-nextgen]

In the case of when working with a server that we haven't got the hand on ... or an other vendor ...
The password of an SFTP or a FTP connector is stored clearly inside the database and could easily be retrieved by anyone who's accessing the database.
Maybe by adding an option (checkbox) like "Encrypt password in DB" and adding a (boolean) property tag ; maybe like that :
1
(Or more secure a checkbox like "Encrypt all connection properties" IP/username/password ...)
For the encryption method, i don't know what kind ... Maybe Mirth could encrypt with his own method. (build-in, certificate, ... ?)

Thank's

Imported Issue. Original Details:
Jira Issue Key: MIRTH-762
Reporter: antaris
Created: 2008-02-07T05:39:54.000-0800

[rbeckman-nextgen]

There will have to be some sort of keystore file to store the key for decryption. If the key is simply stored in the database, then there is no benefit.

Imported Comment. Original Details:
Author: jacobb
Created: 2008-02-19T18:22:53.000-0800

[rbeckman-nextgen]

Perhaps now we could leverage the same keystore we use for encryption of messages, but for specific connector properties.

Imported Comment. Original Details:
Author: jacobb
Created: 2013-10-16T17:02:37.000-0700

[rbeckman-nextgen]

Wondering if this would also mean that a channel export would no longer contain a plaintext password? (more secure)

Imported Comment. Original Details:
Author: johnhd
Created: 2014-03-21T05:48:25.000-0700

[rbeckman-nextgen]

It might, because now we're storing the entire serialized channel XML blob in a single column.

Imported Comment. Original Details:
Author: narupley
Created: 2014-03-21T06:50:27.000-0700

[rbeckman-nextgen]

Also to add to that, realize that for exporting channels (or anything from the Administrator for that matter), you can already encrypt by adding "encryption.export = 1" to your mirth.properties file. Though, that encrypts the entire file, not just specific properties. It's good for channel archival, but not so good for sharing channels with other people who may be using different instances of MC.

Imported Comment. Original Details:
Author: narupley
Created: 2014-03-21T08:38:22.000-0700

[rbeckman-nextgen]

If you share your keystore between two instances of Mirth Connect, then you can also share encrypted exports.

Imported Comment. Original Details:
Author: jacobb
Created: 2014-03-21T10:47:21.000-0700

[rbeckman-nextgen]

What if we integrate this with SSL Manager rather than using the default keystore. Each password could also store an alias name which refers to the certificate that will be used to encrypt it when saving and decrypt it when the channel is deployed. That could be more flexible. Though at that point I'm not sure if the plugin should be named SSL Manager.

If not we could still just add the option to use the default keystore key.

Imported Comment. Original Details:
Author: wayneh
Created: 2014-12-22T15:11:34.000-0800

[rbeckman-nextgen]

IMO, all encryption across the application should be done in the same way. I don't think it would make sense to encrypt some things (message data, exports) with keystore.jks, while at the same time encrypting other things (like passwords within connector settings) using the SSL Manager. Since not everyone will have access to the SSL Manager, I would lean more towards using Mirth Connect's built-in encryptor (with the keystore in appdata).

Imported Comment. Original Details:
Author: narupley
Created: 2014-12-22T15:52:01.000-0800