How to hide properties on Liferay 7

[Edward A，修改在6 年前。]

Hi!

We are working in the development of an intranet using Liferay, and there is a request from our client that we do not know how to address, so we kindly ask for your help.

Our client does not want us to store the DB connection credentials on plain text; e.g. portal.properties, server.xml. For this reason, what we need is a way for us to hide this information or encrypt it, though we don't really know how this may affect Liferay.

Has any of you faced an issue like this before?, what did you do?

We beg you, if you are going to be kind enough to help us with an answer, please make sure to elaborate on how you would implement it or where we could find the missing doco for an scenario such as this one. So far we've seen that you can provide the connection through JDNI instead of using JDBC, but that does not really solve this.


Thanks for any help

[David H Nebinger，修改在6 年前。]

Edward A:

We beg you, if you are going to be kind enough to help us with an answer, please make sure to elaborate on how you would implement it or where we could find the missing doco for an scenario such as this one. So far we've seen that you can provide the connection through JDNI instead of using JDBC, but that does not really solve this.

JNDI is the only option, actually. You can lock down the server.xml file so only the tomcat user has read access to it, but otherwise that's going to be the only path

As a thought experiment, let's assume that you could store the credentials encrypted on the filesystem. That solves the client's unreasonable request, but now the software needs to be able to decrypt the credentials so it can actually log into the database.

So, how do you intend on doing that? Put the password for the encrypted file somewhere on the filesystem so you can read it and use to decrypt the other? There goes your security. Even if you put it in the code, it is going to be part of the jar and I, the nefarious hacker, can use standard tools to find it in the decompiled classes so boom, there goes your security.

But being the skilled hacker that I am, I wouldn't even worry about it. Because the database connection itself is susceptible to sniffing. So if I had access to the box but couldn't open the file to get the password directly, all I need to do is sniff the wire to see the credentials being submitted to the server.

I get it. Folks hear about things like Equifax and for a short while everything has to be encrypted, protected and secured. But there's a difference between taking appropriate security measures (which we should all do) and mandating outrageous, impossible or ineffective things in order to "heighten" security.

Trust me, the JNDI option is the best solution. The DB URL and credentials are stored in server.xml or ROOT.xml and you should take steps to ensure that only the tomcat process can read the file. Networking rules protecting the database should only allow access from the app server itself, so if someone could carry away the creds the database would not allow them to connect. All deployed web apps can use JNDI lookups to get the connection, but the details for the connection are not exposed.

If a hacker got so far as to be on the system and had permissions to read the file, you have way bigger problems than just the fact that the database credentials have been exposed.







Come meet me at Devcon 2017 or 2017 LSNA!

[Edward A，修改在6 年前。]

Hi

Thanks so much for taking the time to participate on this thread, David. It is always good to see you. Although I do understand where you're coming from, I don't think that what you suggest necessarily applies to our case. Nonetheless, it is my fault for not explaining why they need to take this measure.

What our client told us is that a team of developers will have access to the files of the liferay portal once it has been deployed, but only one person should have access to the codes necessary for mail and database connection. For that reason, leaving the contents of portal-ext.properties as plain text would allow all the people with access to the project to see these codes.

As you can see, they are not so worried about an external attack as they are about keeping these codes safe from misusage. I think they are being completely reasonable, albeit a little paranoid as well.

In any case, we would appreciate if you would take a look at what we have come up with:

• Create a portal-ext.properties file that will be edited by the person with access to the codes.
• Using the passcode, this person creates a decrypted file and proceeds to safely delete the original file.
• Then they run blade server start.
• The startup.sh will do what it normally does, except that now it will also run a command that will ask for a passcode
• The passcode entered will be used to attempt to decrypt the file. If it fails, the program lets you know that the passcode is incorrect and asks them to try again. Otherwise, a decrypted portal-ext.properties is created and the program runs catalina.sh.
• Once Liferay has started and is running we proceed to safely delete the decrypted file.

What do you think about this. Is there anything we might be overlooking?

[David H Nebinger，修改在6 年前。]

Edward A:

What our client told us is that a team of developers will have access to the files of the liferay portal once it has been deployed, but only one person should have access to the codes necessary for mail and database connection. For that reason, leaving the contents of portal-ext.properties as plain text would allow all the people with access to the project to see these codes.

Hey, Edward. For security purposes, I wouldn't use portal-ext.properties anyway. The properties are always visible to code running int the portal. Most properties are visible within the control panel on the systems admin page, there's a tab for properties where you can see them. Now Liferay does support marking some as "protected" so the control panel will only show the chars as "*", but that's far from secure. You can get to the script control panel and print them using a good old groovy script.

When I say JNDI, I usually put those settings into tomcat's conf/Catalina/localhost/ROOT.xml file. You set the permissions on this file so only the tomcat process can read the file, no one else.

There is no reason that the developers would need any kind of access to the conf directory anyway.

As you can see, they are not so worried about an external attack as they are about keeping these codes safe from misusage. I think they are being completely reasonable, albeit a little paranoid as well.

Well, I'd say it is a lot paranoid. If you don't trust your developers, you have a real problem. After all, they can do a lot of damage and misuse even without the database credentials.

What do you think about this. Is there anything we might be overlooking?

Liferay can take some time to start up. If I'm that evil developer, I'd be sitting there waiting for you to try to start the process so I can cat the properties while Liferay is starting up.

Being password based, you won't be able to auto-start tomcat when the system restarts.

Liferay uses Easyconf for the properties file handling. I only mention it because you can configure Easyconf to "watch" the file for changes. This is not enabled by default, but if you are using that feature, deleting the file after startup could have adverse effects. It is possible that other parts of Liferay "watch" this file, but nothing springs to mind...

I don't get the paranoia over the DB though. It shouldn't be a production database, because you never develop against the prod assets as it is too easy for untested code to break things. So that means there is a development database but that too the developers shouldn't have access to? As a developer, DB access can be necessary to test out SQL, service builder code, etc.

So basically your list will work, but it is far from foolproof...









Come meet me at Devcon 2017 or 2017 LSNA!

[Olaf Kock，修改在6 年前。]

The correct way to somewhat protect your password is to not put it into portal-ext.properties at all. If it's in there, anybody who is running code on the server gets access to the properties anyways, no matter what the read-permissions on portal-ext.properties are.

Use JNDI, configure your appserver to provide the database. However, with regards to the security of this, you might be interested in Tomcat's FAQ for this question. Money quote with regards to encrypting the password:

Write your own datasource implementation which wraps your datasource and obscure your brains out (XOR and ROT13 are great candidates for this since their strength matches the protection you'll actually get)

For development databases: Do not bother. Have everybody run on their own development databases. There should be no production data in there anyways, so no need to protect anything.

[Edward A，修改在6 年前。]

Hi!

Thank you David and Olaf for helping us out with this issue. We will trust your years of experience and go with the solution that you have proposed. We will need to let our client understand that this is the best approach to the situation, and I hope that they will understand.