web stats
Encrypt password for database in mirth.property - Mirth Community

Go Back   Mirth Community > Mirth Connect > Development

Reply
 
Thread Tools Display Modes
  #1  
Old 09-19-2014, 11:44 AM
shrikantpatel shrikantpatel is offline
Mirth Newb
 
Join Date: Apr 2014
Posts: 7
shrikantpatel is on a distinguished road
Default Encrypt password for database in mirth.property

From what i read\see the database password in mirth.property is plain text. Can or is there way we can store encrypted password instead of plain text?
Reply With Quote
  #2  
Old 09-19-2014, 12:13 PM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,119
narupley is on a distinguished road
Default

If you want Mirth Connect to be able to automatically start up, then no. If you encrypt the password, Mirth Connect would have to have some way of decrypting it. And where would you put that password/private key/whatever?

EDIT: Sorry, actually that's not quite right. The database password can be encrypted using the Mirth Connect keystore, if you set the following in mirth.properties:

Code:
encryption.properties = 1
However, the storepass/keypass for the keystore itself will still remain unencrypted. So if a user has access to conf/mirth.properties and appdata/keystore.jks, he will still be able to gain access to the database password through the keystore.
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.

Last edited by narupley; 09-19-2014 at 03:05 PM.
Reply With Quote
  #3  
Old 09-28-2014, 03:21 AM
paulagregory paulagregory is offline
What's HL7?
 
Join Date: Sep 2014
Posts: 1
paulagregory is on a distinguished road
Default

great, it will be a new topic for me to learn being an IT student..
roxy palace australia

Last edited by paulagregory; 09-28-2014 at 10:20 PM.
Reply With Quote
  #4  
Old 01-13-2015, 07:43 AM
ahart ahart is offline
OBX.2 Kenobi
 
Join Date: Oct 2014
Posts: 56
ahart is on a distinguished road
Default

Hello Nick,

Sorry to resurrect this thread, but this is an issue for us where Government requires things to be FIPS 140-2 compliant.

One idea that occurred to me: why not have a configuration property that would be to specify a Java class responsible for decryption of config properties? If this java class is not specified, then it would default to the way it works now. If it is specified, then that class would supply a decrypt method allowing Mirth to decrypt db/keystore passwords. Mirth defines the interface; we supply the implementation.

Other than that, has anyone else ever customized the code for this purpose? I only have the 2.x source code downloaded at the moment, but at some point this will become an issue for us.

Last edited by ahart; 01-13-2015 at 07:53 AM.
Reply With Quote
  #5  
Old 01-13-2015, 09:58 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,119
narupley is on a distinguished road
Default

You can't have your cake and eat it too.

The moral of this story is that if you want things to start up auto-magically, then at some point, somewhere, a (basically) cleartext password is going to be required. You can obscure the hell out of it seven different ways, but it's still going to be an essentially polynomial problem to solve (contrasted with encryption, which is theoretically NP).

You can put it in a JAR file loaded on startup via some config property, sure. But JAR files (and executable files in general) are always reverse-engineerable. And if you don't minify or optimize the JAR compilation/packing, it's actually really easy to do, too. Again, it would be obscured, but not computationally infeasible to crack. Plus if a user has access to the JAR file and has even a little bit of Java skills, he can just drop it into a project with some main class that calls the loader interface method, and bam, he has the password.

You might think you could put the database password in a separate file that's "locked down" by the OS, sure. But how does the machine "lock down" that file? With another password? By only allowing a specific user to access it? And how does that user log in? With a password? Where does that password go? Chicken and egg, my friend.

We could add an option so that MC doesn't automatically start up, and instead the Server Manager prompts for a password whenever you need to start/stop the service. Obviously, a lot of people wouldn't like this because now you have to physically type in the password every time.

Auditors (and project managers trying to appease auditors) don't understand all of this, and so they don't like these answers. But there's no getting around the hard facts. There are basically three options:
  1. Settle for obscuring (but not truly securing) the password somehow. Putting it in a separate "locked down" file falls under this category because MC would have to have some way to access that file. So really you're just moving the goalpost from "obscure the database password" to "obscure the password/method that gives us access to the file that gives us access to the database password".

  2. Settle for having the password "secure" for everyone except for administrator/root accounts. If the MC installation directory is already in some place that only admins have access to, then the problem is already solved. If not then moving the password to a separate location would work, but the MC service/daemon would also have to run under the same admin/root account.

  3. Settle for losing the ability to start MC automatically, and having it always require user intervention. That user intervention will likely require a password. And if everyone forgets that password or gets hit by a bus, you are completely screwed. But hey no problem, just write the password on a post-it note and keep it in your drawer just in case!

If you want to be truly "secure" and not have any computationally crackable avenues to the database password, then your only option is #3, to lose the ability to have Mirth Connect start up automatically.

FYI, this is not an issue isolated to Mirth Connect. It's a simple fact of security, applications, and passwords to external systems. Look at Apache Tomcat's FAQ for example (http://wiki.apache.org/tomcat/FAQ/Password):

Quote:
Passwords

Why are plain text passwords in the config files?


Because there is no good way to "secure" them. When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method. So at best, the password is obscured - but not really protected. Please see the user and dev list archives for flame wars about this topic.

That said, any configuration file that does contain a password needs to be appropriately secured. That means limiting access to the file so that it could be read only by the user that Tomcat process runs as and root (or the administrator on Windows).

...

A cultural reference:
So, my question to you is, what exactly is your goal? Do you want the database password to be truly secure? Or do you want to fake it and make it look like it's secure, enough so that a na´ve auditor will check it off his list?
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.

Last edited by narupley; 01-13-2015 at 05:29 PM.
Reply With Quote
  #6  
Old 01-13-2015, 01:27 PM
ahart ahart is offline
OBX.2 Kenobi
 
Join Date: Oct 2014
Posts: 56
ahart is on a distinguished road
Default

Ok, I take your point. But, unlike the Tomcat example above, our source code isn't going to be freely available, so while you might consider it just another level of obfuscation, it certainly helps with the conf file being shoulder surfed or revealed when someone (who probably shouldn't) mails it.

So, yes, the purpose is to avoid having it as a finding in some Fortify scan.
Reply With Quote
  #7  
Old 12-10-2018, 06:29 AM
con con is offline
OBX.1 Kenobi
 
Join Date: Nov 2018
Location: Berlin
Posts: 33
con is on a distinguished road
Default purpose of encryption.properties

If you run the msql instance on the same server as the mirth installation, is there still a security-related benefit of the encryption.properties to be set to 1 beside that it is stored in the keystore?
Reply With Quote
Reply

Tags
database, encrypt, mirth.property, password

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 09:35 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation