search

rbeckman-nextgen / test-mc3

0 stars 0 forks source link

Encrypt sensitive connector properties like passwords #745

Open rbeckman-nextgen opened 4 years ago

rbeckman-nextgen commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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