I would like to know if there is a way to hide sensitive information (assume data that could be used for insider trading, for instance) from DBAs in an Oracle 10g environment. Is Oracle Database Vault the right tool for the job, or is there something else I should be looking at?
DB Vault will provide you with the functionality you are looking for, but you will still need someone (or group) who can act as an ultimate administrator. They will need to be very mildly technical, but certainly not a full-fledged Oracle DBA. I would also strongly recommend you use a consultant who specializes in security to design your implementation. A poor implementation can lead to a system as insecure as before DB Vault, or so complex that change or work comes to a halt.
You'll also want to make sure you use Tablespace Encryption, and I would suggest encrypting your backups as well (Oracle Secure Backup/OSB provides this functionality at the individual DB level as part of the software).
I am not really sure if you can really prevent an DBA from seeing the data of the database. If you want to be sure that they are not able to understand the data that is stored in the database, try encrypting them. If you are just concerned about being compliant with the rules and regulattions (like HIPAA and Sarbanes-Oxley) than go with Oracle (Database Vault seems the way to go) and ask an Oracle Consultant how to set the various switches to be compliant.
Google returned following pdf as one of the top results for Oracle Database Vault. It is a good document to start thinking about security.
Related
I have a program written in Delphi 7, which uses a MS Access 2000 database as the backend.
I have password protected my MS ACCESS 2000 Database file (*.mdb) with a 16 character password consisting of a misture of Numeral, control, UpperCase, and LowerCase characters.
However, it looks like there are a number of programs on the market that claim that the password can be retrieved. What is the purpose of this database password if that is the case? Is there anyway to make it so it is not retrievable? Tighten the encryption so to speak?
thanks
MS Access 2010 uses better encryption and has some other features. SQL Server Compact edition gives you a lot more security but is still appropriate for a desktop app.
Otherwise, go with a server database: mysql, sql server, oracle. Most have free versions.
Is there anyway to make it so it is
not retrievable? Tighten the
encryption so to speak?
It depends; you can either change your database and look for a more secure one (e.g. MS SQL Server Compact Edition), or if you want to stay on MS Access and security of the data is important to you, go for encrypting important fields using a good encryption algorithm (e.g. AES).
If you are going to encrypt your fields, you can do it transparently in Delphi; each DB field in Delphi is derived from TField class, and has two events called OnGetText and OnSetText. OnGetText is fired every time you try to read the field's data, and OnSetText is fired every time you try to write to the field. You can encrypt a field data whenever OnSetText is fired, that way, the encrypted data will be saved in the database. On the other hand, you can decrypt a field data whenever OnGetText is fired, that way, user will always see and work with the decrypted data. The whole process would be transparent to the users.
Of course you should take note that encrypting/ decrypting fields every time they are being read or write has performance drawback depending on number of fields to be encrypted, their size, frequency of reading or writing them, and the encryption algorithm which is used. It's better you just encrypt the important fields.
Another option could be to encrypt the whole MS Access database file, and decrypt it whenever your application is connecting to it, but that way, the file is secure as long as your application is not running; once your application is running and the file is decrypted; the file is exposed to others.
What is the purpose of this database password if that is the case?
It makes people who think Access is a real database feel good about it.
Is there anyway to make it so it is not retrievable?
Stop using Access.
Tighten the encryption so to speak?
Not in Access. However, if you stop using Access and use a real database, you'll find that you can also have real security.
If security is a requirement then you should not be using a Jet database or any other file-sharing database architecture. It's as simple as that.
What is the purpose of this database
password if that is the case?
The purpose is to get people to upgrade to MS SQL Server and buy licenses for that as well. There are things MS will never fix.
On the other hand they have a free version of MS SQL Server which is not so crippled so you don't have to start paying through your nose unless your system will actually grow to need a full MS SQL Server.
However, if you develop systems like that (with no plan and not understanding limitations of the technologies you choose), you are most likely to lock yourself into proprietary features, for better or worse.
EDIT:
Here is quote directly from MS
Note Although the model and
techniques discussed in this article
enhance security, the most secure way
to help protect your Access data is to
store your tables on a server, such as
a computer running Windows SharePoint
Services 3.0 or Microsoft Office
SharePoint Server 2010.
Use crypt aes instead of standard mechanism.
I posted this question on Experts-Exchange as well. This is the kind of answer i was looking for (not critisism). Although this person eventually tells me to switch datbabases, he clearly explains why, without critisism:
DatabaseMX:
As you've discovered, there is essentially no security in an Access db password, prior to A2007. The are 1000's of tools (some free) that can immediately hack an Access password. A2007/10 is using an improved password paradigm ... it's security level is not clear yet.
"Is there anyway to make it so it is not retrievable"
No. It's only slightly better than nothing, depending on your specific environment where the mdb will be used.
"What is the purpose of this database password if that is the case? "
It was just a bad implementation. Period.
With A2003 and prior, the best you can do are a combination of the following:
1) db password
2) Add User Level Security
3) Create an MDE to protect code. But event an MDE can be hacked.
So, IF ... you really need better security, you will need to look at SQL Server or equivalent platform.
mx
My customer is a dental practice that has bought a piece of practice management software. This software was installed on their local server, including a patient database, a schedule and all manner of medical records. Now they want me to write some utilities for them that aren't provided with their package, and for this I need the ability to query this database.
I tried calling tech support of the software manufacturers (Patterson/EagleSoft), and it's difficult finding anyone who understands the technology enough to answer my questions. As far as I can tell, there's no API for their software, and understandably they're reluctant to tell me how to query the DB directly, programmatically. They do have an interactive query window, but obviously that's no good for writing automated queries. All that they would let on is that somewhere there's a SQL Server DB, but the ODBC drivers to connect to it are SQL Anywhere drivers (huh?).
So I searched around on the server and couldn't find any database files. Then I discovered that the installation creates some kind of proprietary virtual machine, which is only visible to the EagleSoft software. But while they've been very good at insulating their DB in layers of obfuscation, they have left open an ODBC driver, which is indeed an SQL Anywhere connection.
Now after that fascinating and lengthy preamble, here is my question: What queries can I run over this ODBC connection to interrogate the DB as to its structure? If it's a SQL Server DB underneath I could use the sysobjects table, but I don't fully grasp how you can use a SQL Anywhere ODBC connection to connect to a MSSQL DB. And If they were misinforming me and it really is a SQL Anywhere DB underneath, what are the queries to run to get at the DB structure?
And if there's anyone else out there who's ever succeeded in actually querying EagleSoft (or any similar proprietary package) - please tell me how you did it!
Turns out the simplest way to do it was to write a little app using OdbcDbConnection, and connect using the DSN installed with the software. It took one probing 'select * from sysobjects' to reveal that it is, indeed a MS-SQL database underneath all that, and I'm good to go from there!
I'd use a tool like squirel which is great at browsing any database to check if anyone was successful with "SQL Anywhere" this google result:
http://blog.gmane.org/gmane.comp.db.squirrel-sql.users/month=20091001
Shows that others have managed to get squirrel to do this. It's quite easy to use... assuming of course you manage to get the connection working!
A few tools that might help are SQLWorkbench and Django. I use SQLWorkbench to copy the data from the production system into a Postgres database so I can hack on it without damaging the production environment. Then I use Django's inspectdb to generate models of the database environment. From there it's easy to create 'views' into the database and templates to display exactly what I want.
UPDATE: As of Eaglesoft 19, it looks like Patterson has password protected the database and they have gone out of their way to prevent users from getting at the data without paying them for access.
UPDATE: Like I mentioned before, Eaglesoft 19 has a locked-down version of the database. For read-only access you can call Patterson and ask them for the password to the "Database Admin" section of their "Technical Reference" tool that is installed on your server. Once you are in there, there's an option to set a read-only password for access to the database. The username is 'dba' and whatever password you set. Some times it takes a bit of back-and-forth with them to give you access, but my solution was to say "We've been putting patient data into Eaglesoft for over a decade and we've always had access to the database. Now you're restricting it and telling us we have to pay for access. It sounds like you are trying to extort money by holding our data hostage. I should probably run this by our legal team."
EDIT: Nov 18 2022: You can still easily get read-only access to an Eaglesoft database in 21.20.08 (the latest version) by calling Patterson and getting the "day password" for Technical Reference. From there you can enable a read-only user. Based on some of the changes Patterson is making to their application architecture and the database, I suspect they will stop using direct connections to the database in the next year or two. When they make that change, you will only be able to access the database through their API Server. After playing "phone tag" with one of their salesbros for several weeks and doing some light social engineering, I managed to get their price list for going through the API server. It's atrocious. Most offices pay ~$500/mo to Patterson for free tech support and free upgrades. They want developers to pay nearly as much per office for access to the API. They've realized they can lock practices out of their own data and monetize it. We are working with a company that is actively developing a replacement for Eaglesoft to get away from this horrible vendor lock-in.
I have written my own PHP driven website to access and manipulate data in my eaglesoft database. You simply create odbc connection to local DNS entry and done. To see database structure you can use the technical reference included in eaglesoft or advanced query tool.
I have a desktop application that needs to read data from a database, both installed on client computer.
That data in database must be encrypted, to deny client access, and protect data.
I need to know what kind of database to use that can supports encryption, because the amount of data in some tables will be very huge, I will need efficiency too.
I read some about this on web and perhaps SQL Server Compact Edition will be a good choice.
Can someone help me with this point?
Thanks
SQL Server 2008 includes a feature called Transparent Data Encryption which may do what you need. I don't know if Compact Edition contains this feature. A little googling with those keywords should get you started. I don't normally advocate using SQL Server, but in this case I'm not aware of any similar features from other DB vendors (but they must exist...).
That said, what do you hope to gain by encrypting the data? If this is entirely client-side, then the client is going to have the key to decrypt the data. At best, you're making a slight hurdle for people to get at your database contents. It won't be secure by any meaningful definition.
You cannot prevent a determined attacker from accessing the decryption key and accessing the database. This is effectively a copy-protection scheme, and they are all broken.
Update: The question states, "That data in database must be encrypted, to deny client access, and protect data." If the client has access to any application that can access the database, he has access to the key used by the application, and can bypass the application to access the database directly.
If the inescapable logic has no appeal, consider the anecdotal evidence of failed copy-protection schemes attempted to protect music, games, and other digital assets.
SQLite has an Encryption Extension (SEE) that allows an application to read and write encrypted database files: http://www.hwaci.com/sw/sqlite/see.html
This DB may be a good fit for a desktop application, and is widely used. For example, I believe FireFox uses it internally.
SQL Server CE has no support for encryption whatsoever. You can at best encrypt the database file using the host OS encryption facilities. The file level encryption does not work for databases because to read page X in the file one has to decrypt all pages 1...X-1 to get the encryption key in the appropriate state (reach the proper CBC block state). BitLocker on the other hand works fine as it can decrypt/encrypt pages in the file individually. But BitLocker is a partition level option, not file level. These general considerations apply to any plan to encrypt the entire database file, irrelevant of the product involved (SQL CE, SQL Express, MySQL, Access, anything).
SQL Server has database level encryption. The easiest to use is TDE, Transparent Data Encryption but this requires Enterprise Edition. The other option is to use the cryptographic functions and manage the encryption yourself. Hardly easy to use, but is available in the free Express edition.
Might I recommend SQLCipher? It's a free and open-source implementation of SQLite that supports transparent, page-level encryption. It's similar to SEE, it's under active development, and has experimental support for a number of different ciphers, as it uses OpenSSL for some of its implementation. Full disclosure: I'm one of the developers! We've got a tutorial on using it in iPhone applications that will give you a basic idea of how it works, and there's a comment thread that expands on some related topics. Obviously, using it in Visual Studio will be a tad different than XCode, but you should be able to hook up the linking and get it going in a Windows environment.
I want to distribute an SQL 2008 database to a client and set it up so that the only way to access the data in it is through my application. Can I use Truecrypt for that? Can you think of any other solution?
No, is not possible. This is asked repeatedly and the answer is the same: protecting the data so that is only usable from one application is DRM and SQL Server does not do DRM. There is no cryptographic/encryption or authorization/permission mechanism you can set in place to prevent a legitimate administrator from seeing and using the data as it sees fit, including granting other applications permission to use your application data.
At worst you can encrypt all the data in the client and store only the encrypted blobs, thus rendering it unusable to any other application. This approach looses any advantage a relational database offers (data cannot be searched, queried, indexed, foreign relations and constraints cannot be enforced etc) rendering the SQL Server absolutely useless for your application. Besides, even in this case, short of using a hardware module, the data is not trully protected since the application cannot embed any encryption key in a secret fashion (any key embeded in the app, no matter how obfuscated it is, can be retrieved, always) and relying on the user to provide a secret password means the user can simply decrypt the data.
If you want to use a DRM scheme (which you are actually asking for), use a DRM product.
I've taken a quick look at Truecrypt and it doesn't look like the tool for what you're trying to do.
You should look at SQL Server Logins, Users and Roles. How you use these will depend on how you setup your database connection. If you can provide more information about how you are connecting I can try and help further.
I don't want customers to be able to make backups of my sql server database and access the tables data etc.
I know there are some products that will encrypt the data in the tables, and their product will decrypt it when displaying in my application.
What products do you guys know of? What options do I have?
(This is a business requirement, however silly it might seem to some hehe).
Update
This is for sql server 2008 express
The problem with encrypting data inside the database is that as long as the database lives on the client's machine (as you indicated, they're running SQL 2008 Express, so I'm betting it lives on the client's desktops or laptops) then they can get into the data. They can set up security on the instance so that they have SA privileges, and from there, they can get the data, period. There's no way around that.
What you have to do is encrypt the data before it hits the database: encrypt it in your application. Inside the app, encrypt the data that you want to store in each sensitive field. As another poster indicated, you don't want to encrypt ID fields because those are used for indexing.
There is the 3rd party xp_crypt. It's been around for years.
It's an extended stored proc (that is, DLL)
SQL Server 2008 supports database encryption natively. Check the documentation for Transparent Data Encryption (TDE).
You can encrypt stored procedures, which can protect your logic.
TDE is available only Enterprise edition.
I can't find if it supports native sql encryption - but you could find this out with a little searching. But if it did you could probably set the database master key with your application and keep all of the decryption/encryption code in your application.
If it doesn't support native encryption, you might want to creat/find your own encryption functions in your application language and lock away the keys in your code.
Transparent Data Encryption will encrypt the database on disk, but is unencrypted in memory, so appropriate security would also be necessary to ensure unauthorised users cannot access the table. As it's an Enterprise-only feature, you can safely move away from it.
SQL Server 2005 and above have built-in encryption features - have a look at Books Online, and especially Chapter 5 - Encryption of Adam Machanic's Expert SQL Server 2005 Development book (technically, Lara Rubbelke wrote chapter 5 though).
Note that you'll only want to encrypt some columns - those that you'll never try to look up, as encrypted columns are pretty much useless for indexing. Adam Machanic's book suggests ways to solve this problem.
Another solution for transparent SQL Server encryption is DbDefence
Free for databases less than 77 MBs.