What is the best way to encrypt columns in SQL Server 2005 Express edition so that no one can steal our database design?
Thanks
there is no best way to do this.
if you obfuscate them you give yourself a lot of pain when debugging. you'll have to change all the queries. there's no good tool for this.
not to mention that the potential dba who'll might have to look at it and tune is going to be lost.
It's probably hard to accpet but your database design isn't something brilliant and new. I'm sure someone else has done it before. So there's no real need to protect it.
I suggest you set permissions for data access, not obfuscate schema. Schema isn't important, data is.
You could encrypt certain db objects like sprocs and views but this is also useless because there are not too hard ways of cracking it.
better secure your database, then encrypt your table scheme
give your application user just minimal rights to your database
secure your connection string http://msdn.microsoft.com/en-us/library/ff648340.aspx#paght000010_step2
Looks like you can only obfuscate Stored Procedures, Functions, Triggers and Views.
Link To MSDN
Related
I'm currently studying web security, purely on my own, to expand my skillset going forward in my career. I've been studying different encryption techniques, how best to employ them, etc.
The current situation I'm thinking about involves a multi-tenant database. Each schema in the database represents a different tenant. The data in each schema needs to be secured not only from outsiders, but from the other tenants as well.
To do this, I would use symmetric encryption, with a different key for each schema. But that's where my question comes in.
There are two ways to handle the keys, as I see it. One would be to have a secure location for storing the keys, like on a separate server. That would still require storing each and every key.
The second way would be re-generating the encryption key each time. The key would be a combination of a series of values related to the tenant that are stored in the database. Each time someone connects to the application, the key is re-generated by putting those values in the exact same order and hashing them.
I'm wondering if the second idea is overkill, or if it is a viable option. In general, though, I'm looking for guidance on how best to design database security policies.
Thank you.
I want to handle some confidential data in one of my web application. So that the data shouldn't able to read by the Developer or Database administrator.
We can easily hide the data from DB administrator by implementing some encryption technique. But still the developer can see the data since he only creating the decryption technique. I want only the end user should see his data.
I can't encrypt data using some algorithms like PBKDF2 or DB side encryption methods Like TDE & EKM because still I need to keep the encryption key somewhere. If I keep in server side or in db the developer can access and decrypt the data. If I keep it in client side, the user can't access the information from a separate machine.
So How to handle this situation? Thanks in advance.
You are heading the direction of Zero Knowledge Web Applications, such as implemented by SpiderOak (see also crypton). These applications typically work by deriving a key from the user's password using something like PBKDF2, and performing encryption/decryption on client side. However, there are a number of complexities to overcome to make it true zero-knowledge, and also to meet usability requirements. One could write an essay on this, but instead I suggest you start by reading the linked references. If you have any questions, let me know.
In a nutshell, the "more zero-knowledge" you want the system to be, the harder it is to realise without sacrificing usability (one example is overcoming the points made in Javascript Cryptography Considered Harmful). However, there are various tradeoffs you can make in order to make it sufficiently difficult to cheat without affecting usability too much.
I need to keep the encryption key somewhere
No you don't. The user only has to remember it. For convenience you could save it in the browser's local storage.
We are going to store some sensitive information about our customers in the db model res_partners.
However we don't want to store this information in a simple text field. We would prefer
some basic encrypting if possible for those fields. We do not want someone who
has access to the db to have access to these fields.
Is there a way we can get this done in openerp or postgres ?
Thank you,
Vishal Khialani
There is no such thing as "basic" encryption. Rot13 is not getting to get you anywhere here. If your data is sensitive enough to deserve protection, then you need to use state of the art cyphers such as Blowfish. I advise you give a good long look at Bruce Schneier's book Applied Cryptography
The easy (and insecure) way to achieve this is to overload the write and read methods of your model to encrypt before writing and decrypt after reading.
The tricky part is storing the encryption key. You could store it in a file on the computer running the OpenERP server (assuming the database is running on another server). This is still pretty weak, as the key will be available in clear on the server, but could still be useful if you don't trust your database server admin, but do trust you openerp server admin. It's still way easier to get the database server in a secure and trusted place, and if required to crypt offline copies of the database (such as backups).
If you want more security, you'll have to send the data encrypted to the client application, and let the decryption happen there, using a user-supplied key. I'm not enough knowledgeable of this part of openerp to say if it is easily feasible or not.
i want to encrypt the data. still i am following to do this on ASP.NET Pages. i came to know that we can apply encryption/decryption on data at Backend means on SQL SERVER. I want to know which is the better way. Will i change it to on SQL SERVER or will go with as it is?
I have studied This link to study which say only required columns should be encrypt/decrypt, not whole database. So please let me know which is better way from both of them.
The problem I would say is that the data and the key are stored on the SQL Server. That means if a user was able to get some type of administrative access, or with the right privileges you would potentially compromise all your encrypted data.
The other problem is what happens if the database is stolen, and then later on some vulnerability was found with the mechanism that SQL server was using? These things happen such as when the padding oracle bug was found with scriptresource.axd http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html .
Thanks to a SQL injection vulnerability found last week, some of my recommendations are being investigated at work. We recently re-did an application which stores personally identifiable information whose disclosure could lead to identity theft. While we read some of the data on a regular basis, the restricted data we only need a couple of times a year and then only two employees need it.
I've read up on SQL Server 2008's encryption function, but I'm not convinced that's the route I want to go. My problem ultimately boils down to the fact that we're either using symmetric keys or assymetric keys encrypted by a symmetric key. Thus it seems like a SQL injection attack could lead to a data leak. I realize permissions should prevent that, permissions should also prevent the leaking in the first place.
It seems to me the better method would be to asymmetrically encrypt the data in the web application. Then store the private key offline and have a fat client that they can run the few times a year they need to access the restricted data so the data could be decrypted on the client. This way, if the server get compromised, we don't leak old data although depending on what they do we may leak future data. I think the big disadvantage is this would require re-writing the web application and creating a new fat application (to pull the restricted data). Due to the recent problem, I can probably get the time allocated, so now would be the proper time to make the recommendation.
Do you have a better suggestion? Which method would you recommend? More importantly why?
Encryption in SQL is really only good for securing the data as it rests on the server, although that doesn't mean that it is unimportant. When you mention that a prime concern is injection attacks or the likes, my concern would be whether or not the database uses a single account (SQL or otherwise) to connect to the database, which would be common for a public internet site. If you use integrated authentication, or connect to SQL using the same credentials supplied to the application, then SQL's encryption might work fine.
However, if you're using a single login, SQL's encryption is going to manage encrypting and decrypting the data for you, based on your login. So, if your application is compromised, SQL may not be able to protect that data for you, as it implicitly decrypts it and doesn't know anything is wrong.
You may want to, as you suggested, encrypt/decrypt the data in the application, and store as bytes in the database. That way you control who can decrypt the data and when (for example, you could assign the key to decrypting this data to those few employees you mentioned that are in a specific role). You could look into Microsoft's Security Application Block, or Bouncy Castle, etc. for good encryption utilities. Just be careful about how you manage the key.
Update:
Although you could potentially use two connection strings: one normal, with no rights to the encrypted data, and one that has the key and the rights to the data. Then have your application use the appropriate connection when the user has the rights. Of course, that's pretty kludgy.
Some practices that we follow:
Never use dynamic sql. It's completely unnecessary.
Regardless of #1, always parameterize your queries. This alone will get rid of sql injection, but there are lots of other entry points.
Use the least priviledged account you can for accessing the database server. This typically means the account should NOT have the ability to run ad hoc queries (see #1). It also means that it shouldn't have access to run any DDL statements (create, drop, ..).
Don't trust the web application, much less any input received from a browser. Sanitize everything. Web App servers are cracked on a regular basis.
We also deal with a lot of PII and are extremely strict (to the point of paranoia) on how the data is accessed and by whom. Everything that comes through the server is logged. To make sure this happens we only allow access to the database through stored procedures. The procs always test to see if the user account is even authorized to execute the query. Further they log when, who, and what. We do not have any mass delete queries at all.
Our IDs are completely non-guessable. This is for every table in the system.
We do not use ORM tools. They typically require way too much access to the database server to work right and we just aren't comfortable with that.
We do background checks on the DBA's and our other production support people every 6 months. Access to production is tightly controlled and actively monitored. We don't allow contractors access to production for any reason and everything is code reviewed prior to being allowed into the code base.
For the encrypted data, allow specific users access to the decryption keys. Change those keys often, as in once a month if possible.
ALL data transfer between machines is encrypted. Kerberos between servers and desktops; SSL between IIS and browsers.
Recognize and architect for the fact that a LOT of data theft is from internal employees. Either by actively hacking the system, actively granting unauthorized users access, or passively by installing crap (like IE 6) on their machines. Guess how Google got hacked.
The main question in your situation is identifying all of the parts that need access to the PII.
Things like how does the information get into your system? The main thing here is where does the initial encryption key get stored?
Your issue is key management. No matter how many way's you turn the problem around, you'll end up with one simple elementary fact: the service process needs access to the keys to encrypt the data (is important that is a background service because that implies it cannot obtain the root of the encryption hierarchy key from a human entered password whenever is needed). Therefore compromise of the process leads to compromise of the key(s). There are ways to obfuscate this issue, but no ways to truly hide it. To put this into perspective though, only a compromise of the SQL Server process itself could expose this problem, something which is significantly higher bar than a SQL Injection vulnerability.
You are trying to circumvent this problem by relying on the public key/private key asymmetry and use the public key to encrypt the data so that it can only be decrypted by the owner of the private key. So that the service does not need access to the private key, therefore if compromised it cannot be used to decrypt the data. Unfortunately this works only in theory. In the real world RSA encryption is so slow that is cannot be used for bulk data. This is why common RSA based encryption scheme uses a symmetric key to encrypt the data and encrypts the symmetric key with the RSA key.
My recommendation would be to stick with tried and tested approaches. Use a symmetric key to encrypt the data. Use an RSA key to encrypt the symmetric key(s). Have SQL Server own and control the RSA private key. Use the permission hierarchy to protect the RSA private key (really, there isn't anything better you could do). Use module signing to grant access to the encryption procedures. This way the ASP service itself does not even have the privileges to encrypt the data, it can only do so by the means of the signed encryption procedure. It would take significant 'creative' administration/coding mistakes from your colleagues to compromise such a scheme, significantly more than a mere 'operator error'. A system administrator would have an easier path, but any solution that is designed to circumvent a sysadmin is doomed.