Steve,
I am not sure what this would give you in terms of real security.
To get to the data in OSC you have several modes of attack:
1) track the data that travels over the internet. Using proper SSL security would cover that.
2) compromise a password to get into the system through the normal front door. Once you are in, you can read all the data you want and encryption of the data inside the database is not going to help there. Although the user name selection on the login screen is nice, an security enhancement would be to make that a user name entry field as that requires two guesses to get in and not just the password.
3) compromise another login on the server machine to get access to the database files. If we assume that the database data is encrypted, would the OSC code operating on the database not have to have that security key as well? Today, it already has the database user and database password in that code already so one you get acess to those files, is pretty much everything open?
Altogether, security is about the weakest link in the total system. So it is about secure access to web pages, difficult to guess passwords, extremely hard to guess system login passwords, no more open ports on the internet side of things that absolutely necessary. Proper partitioning and setting of user and group permissions between what the webserver can access, etc.
Cheers,
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What about the security on the database. If someone is able to get to the data. At least you would have added another level of complexity that they need another password to decrypt sensitive data.
I would assume that the encryption password would be not be stored in the /www/osc directory. But obviously this would be in a directory that the webserver would have access to.
Wouldn't this provide another layer of protection of data?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve,
I am not an expert on these things, and there are various Security-HOWTO's floating around on the net that talk about these things in great depth.
I seems to me that if your server system:
a) is properly configured
b) has proper strong password security
c) no open ports or rougue services (e.g. telnet)
d) has the web server document directories set with user & group ownership so nobody other than just web server itself can get at those files
e) the actual database in a separate disk partition and also locked down with user and group permissions levels so that only the database server has access
f) the OSC database with a unique OSC only database user and password
g) the permissions on the OSC database set such that only that OSC user has access
it's getting pretty darn difficult to get to the actual files and if they do, they would hacked into this system so deeply, any encryption on data within the database would be useless as they would have found all the keys and all the code that would accessed that database as well.
And all this locking down of the server, is pretty much under the system administrator control.
I think you run more risk of a user that has edit or read access to the member database choosing a easy to guess password or leaving his password on a sticky label on his monitor.
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
I have had a few inquires from people about security in OSC and ChurchLedger.com. Particularly to the encryption of data on/in the physical database.
Is this a requirement the community feels would be a good enhancement for OSC?
Steve
Steve,
I am not sure what this would give you in terms of real security.
To get to the data in OSC you have several modes of attack:
1) track the data that travels over the internet. Using proper SSL security would cover that.
2) compromise a password to get into the system through the normal front door. Once you are in, you can read all the data you want and encryption of the data inside the database is not going to help there. Although the user name selection on the login screen is nice, an security enhancement would be to make that a user name entry field as that requires two guesses to get in and not just the password.
3) compromise another login on the server machine to get access to the database files. If we assume that the database data is encrypted, would the OSC code operating on the database not have to have that security key as well? Today, it already has the database user and database password in that code already so one you get acess to those files, is pretty much everything open?
Altogether, security is about the weakest link in the total system. So it is about secure access to web pages, difficult to guess passwords, extremely hard to guess system login passwords, no more open ports on the internet side of things that absolutely necessary. Proper partitioning and setting of user and group permissions between what the webserver can access, etc.
Cheers,
Marco
Marco,
What about the security on the database. If someone is able to get to the data. At least you would have added another level of complexity that they need another password to decrypt sensitive data.
I would assume that the encryption password would be not be stored in the /www/osc directory. But obviously this would be in a directory that the webserver would have access to.
Wouldn't this provide another layer of protection of data?
Steve,
I am not an expert on these things, and there are various Security-HOWTO's floating around on the net that talk about these things in great depth.
I seems to me that if your server system:
a) is properly configured
b) has proper strong password security
c) no open ports or rougue services (e.g. telnet)
d) has the web server document directories set with user & group ownership so nobody other than just web server itself can get at those files
e) the actual database in a separate disk partition and also locked down with user and group permissions levels so that only the database server has access
f) the OSC database with a unique OSC only database user and password
g) the permissions on the OSC database set such that only that OSC user has access
it's getting pretty darn difficult to get to the actual files and if they do, they would hacked into this system so deeply, any encryption on data within the database would be useless as they would have found all the keys and all the code that would accessed that database as well.
And all this locking down of the server, is pretty much under the system administrator control.
I think you run more risk of a user that has edit or read access to the member database choosing a easy to guess password or leaving his password on a sticky label on his monitor.
Marco