I have been database programming for 15 years but am new to servoy. We are looking at using it for a new development in Australia. I understand that Servoy handles the security of access to the underlying SQL tables with its own users and groups, and effectively connects to the database as ‘sa’ (root) as defined in the dataprovider.
Whilst we can secure the transport using SSL I am concerned that the root password used by the dataprovider is held in plain text in servoy.properties - and displays on the console in plain text when server runs.
In most other solutions the passwords are hashed for storage and never stored/displayed in plain text. Coming from other data backgrounds and the fact our application will handle patient data this is causing me concerns.
Can anyone explain why this shouldnt be a problem? I cant find any guidance in the manuals as to how to secure servoy.properties and/or the console.
Regards
Al.
I’ve asked this question once also so I will take from my memory whatever I can remember.
It is Servoy’s believe that the database always runs in an environment of the database owner. So there should be no issue with the password/username in readable text.
Next to that the security system of Servoy itself has a hashed password (can’t be reverse engineered) so using the solution by an unauthorized user is not so simple once you secured it.
You can not find any guidance on how to secure the properties file because you can’t.
Hope this helps a little.
You can not find any guidance on how to secure the properties file because you can’t.
so you can’t secure servoy.properties…which by definition contains the database connection credentials in PLAIN TEXT. Isnt this a really big security hole or am I missing something? (I hope I am).
Al.
Well, unless I overlook something you simply make sure that nobody can access the file.
If they can or should it is simply a matter of creating your database in a way that it is hard to find that correct (cor)relation between your table data records…
No client can ever access that file on your server unless you allow them to!
…but what about a sysadmin - who would have access to the file, but maybe shouldnt have access to the information in the database? Seems you have breached all confidentiality/privacy requirements if you are relying soley on the operating system to protect the integrity of your db connection?
There are many situations (medical, legal, financial) where you must prevent sysadmins having root access to the database. By putting the root access password in plain text in a file on the OS you have broken this privacy requirement.
Please can someone tell me I am wrong and there is a flaw in my lgic but it seems that this would blow a hole in any HIPPA/Sox compliance?
Al.
Hi Al,
I suggest you put in a feature request in the support system.
Mention the HIPPA/Sox compliance issue as well in there because it’s important.
alb:
By putting the root access password in plain text in a file on the OS you have broken this privacy requirement.
There’s no need to use the database root password, just create a database user with enough privileges to connect to the servoy repository and to the other tables used by Servoy. Having said that I agree with you that the properties files shouldn’t be in cleartext.
…but you dont even need to be root for this to break all security rules.
I have a table that contains patient information. The OS admin has no rights to see this data (and under law must not have access to it).
I create a servoy account that can read the data table and I put the password in PLAIN TEXT in servoy.properties.
Now the OS admin can use the credentials to read the private information.
I cant beleive no-one has picked this up before.
This configuration would never get past any of the IT security audits we have to undertake.
Hasnt anyone in Servoy thought of this or arent you paranoid enough?
All you need to do to fix this is encrypt the password in servoy.properties.
Anyone got a fix as at the moment this seems a really fundamental flaw that would prevent servoy being used for any serious financial/private application.
Al.
I cant beleive no-one has picked this up before.
I think I answered that one. The thing is that is was never a real issue for me and many other I guess…
Anyone got a fix as at the moment
I think this one is answered as well. Please do as Robert, spot on, suggested and file a request at the support system. That will guarantee the attention of the Servoy development team…
We always assume the Servoy server is running in a secure environment itself, namely your server.
If you cannot thrust your server environment itself what can be trusted at all? Imagine what could happen if someone could put malicious beans/plug-ins there which are shipped to all your end users PCs.
As mentioned in this thread Servoy itself does hash the Servoy user passwords, but this is not possible for database user/connection password because the database requires them plain text.
Encrypting the properties file is very hard without asking for a password during server startup (or even impossible) since the public/private key should be in the binaries of Servoy, from which it could be extracted.
The only safe way would be asking for a password during server start-up to decrypt the properties file, but considering this you better use file encryption as found in windows XP for example (which is related to your OS log-in)
Maybe a completely dumb idea, esp. as I have almost zero understanding of Windows permissions … but would it work to put the properties file on a separate box on which the not-completely-trusted sysadmin could not access the file, and on the Servoy server put a shortcut to the actual file location on the other box? Would Servoy Server work if instead of an actual properties file in the expected location, it instead found a pointer?
kazar
You could make the file only be read-/writable by the user which Servoy Server is running under?
This should work for Windows and the Unices (Mac OS X/Linux/Solaris/etc.)
Or are you running the server as root/administrator?
Just a thought.
kazar:
…Would Servoy Server work if instead of an actual properties file in the expected location, it instead found a pointer?
If the Servoy server can read it, so can the server admin controlling the server it seems to me. (an indirect pointer will not really help)
Jan Blok:
kazar:
…Would Servoy Server work if instead of an actual properties file in the expected location, it instead found a pointer?If the Servoy server can read it, so can the server admin controlling the server it seems to me. (an indirect pointer will not really help)
OK, about to expose what is probably a gross misunderstand of this whole area of technology …
… but can’t an application or service be assigned to a group? And couldn’t the actual properties file on the remote volume belong only to that group in which Servoy has admin rights but this not-completely-trusted sysadmin does not? If this could be done then Servoy could read the properties file via shortcut but sysadmin could not.
Which really begs the question why you would have a not-completely-trusted sysadmin allowed to muck around on this box anyhow. Even if they could not read the properties file, with admin priv’s there is PLENTY of damage that could be done, keystroke readers could be installed, wahtever.
So I’m more in the “secure your server and vet your sysadmin staff” camp. I’m just tossing this (perhaps silly) idea out there about moving the properties file to another volume/directory with priv’s that pertain to Servoy but not to Sysadmin.
And it makes me wonder why folks think you could completely satisfy HIPPA regulations by means of technology alone. SOMEONE in the organization must have full dba access to the database in which the HIPPA-sensitive data is stored. Which means the regulations (which I’ve only read about, but never read) have got to allow for one or more individuals in the organization having access.
The bottom line will ALWAYS come down to the trustworthiness of the people you allow near the data, and can NEVER be controlled completely via technology.
Maybe some of the dev’s here who are intimate with the regulations could comment, too.
In many scenarios division of administrative function is one of the key tenets of security and audit in a government scenario. Why wouldnt it be possible for the servoy.properties to be encrypted and decrypted with the java keystore that servoy already uses? Then the keystore could be setup by the information administrator (ie the person with legal access to the data) and the password on the keystore (which is not stored in plain text) would prevent browsing by non-authorised admins? I setup the keystore on a server last night and it took me about 5 minutes.
Just a thought.
If plain text is not a problem why does no other app/OS store it that way? Why not just store the passwords for the entire server in plain text? After all only the really trustworthy admin will ever see them so what could be the problem? I think you need to get a little more paranoid (or maybe I am too paranoid).
I’m going to follow up with our security advisor and Defence Signals and will post back to this list when I get an answer. (and accept with good grace if I am wrong).
Al.
What about adding a checkbox in Servoy Server Admin to store passwords encrypted instead of as clear text?
swingman:
What about adding a checkbox in Servoy Server Admin to store passwords encrypted instead of as clear text?
The point that Jan Blok raised is that you need to encrypt it with a key. So where do you store that key?
Fill it in when you start Servoy Server?
Or have Servoy encrypt it with a default key ? Not very secure.
Exactly, but we made an improvement after all in the upcoming Servoy 3.0 rc4, it is vastly more safer, but not absolutely secure.
In the property file we now encrypt the values for the keys containing the string “password” with keystore keys (can be default SSL one)
So now the db-admin can enter the db passwords in the adminpage, without the system/server admin ever knowing the db passwords.
alb:
In many scenarios division of administrative function is one of the key tenets of security and audit in a government scenario. Why wouldnt it be possible for the servoy.properties to be encrypted and decrypted with the java keystore that servoy already uses? Then the keystore could be setup by the information administrator (ie the person with legal access to the data) and the password on the keystore (which is not stored in plain text) would prevent browsing by non-authorised admins? I setup the keystore on a server last night and it took me about 5 minutes.
Just a thought.If plain text is not a problem why does no other app/OS store it that way? Why not just store the passwords for the entire server in plain text? After all only the really trustworthy admin will ever see them so what could be the problem? I think you need to get a little more paranoid (or maybe I am too paranoid).
I’m going to follow up with our security advisor and Defence Signals and will post back to this list when I get an answer. (and accept with good grace if I am wrong).
Al.
Well, there’s a major difference between storing an OS password and a database password! A OS password is stored using one way encryption: when you login whatever you type in is encrypted and compared to what is stored, obviously this isn’t possible with passwords in the property file as they have to login to the database server. To store those passwords secure there are only two really secure possibilities: one is to key in the passwords everytime you fire up your servoy application and the second to make sure your file is in a secure location. The first one is not very convenient and the latter one is what we already support. The solution you suggest is not secure.
jaleman:
To store those passwords secure there are only two really secure possibilities: one is to key in the passwords everytime you fire up your servoy application and the second to make sure your file is in a secure location. The first one is not very convenient and the latter one is what we already support.
There are situations where the inconvenience of entering a password to open a DB is exactly what is required. For my customers, I routinely require them to log in to the UI with a password, to establish permissions to access different parts of the solution. I also require the same level of security for accessing the SQL db, whether it’s throught the Servoy UI, or direct queries on the db. With Servoy, I don’t currently have that, though the new feature in Servoy 3.0 rc4 is a big improvement.
It would be brilliant to optionally secure the db by requiring a user to enter a password - stored in Servoy as a one-way hash and not in plain text for prying eyes to find.