Recently a friend and I were talking about securing stored procedure code in a SQL server database.
From distant memory, I'm pretty certain that "with encryption" is incredibly easily broken in all versions of SQL Server, however he said it has been greatly improved in SQL 2005. As a result I have not seriously considered it as a security option in any systems I have ever worked on.
So in what scenarious could "with encryption" be used, and when should it be avoided at all costs?
It can be used to hide your code from casual observers, but as you say: it's easily circumvented.
It really can't be any other way, since the server needs to decrypt the code to execute it. It's DRM, basically, and fails for the same reason as all the other DRM does - you can't simultaneously hide the data, and allow it to be accessed.
#Blorgbeard
Good response, the MSDN documentation on "WITH ENCRYPTION" seems to agree with your point, now calling it "obfuscated" rather then encrypted.
I've met a few developers who were completely unaware of this point however. Hopefully this question/response will inform others too.
Yes, it's easily broken. I had a situation this past week where I had to decrypt several sprocs that a former developer had encrypted for a client of mine. After decrypting it, which took a moderate effort, I wouldn't rely on that for any means of protecting intellectual property, passwords, user ids. Anything really.
Related
My client is utilizing software that is SQL-based, the database having been set up by the software vendor for us. During a call I had made to the software vendor to ask them to connect to the SQL server to look at a problem we were having with the software, the software vendor told me that they could not proceed with troubleshooting and investigating the issue because Always Encrypted had been set on the database. Unfortunately the support technician could not tell me much about this, only that it was a road block for them and that it needed to be disabled, and that managing SQL databases to that extent was out of scope for their support.
I tried to look up how to disable or remove that feature from our database but all of the information I have found so far is about setting it up, not taking it down. I haven't tried to "tinker" with this at all on my own as what I have read so far tells me that this is definitely something that should not be touched without sufficient familiarity with managing SQL databases to know that modification of that feature on the database won't have potential negative ramifications (besides the data not being encrypted).
How can I remove or disable this feature from our database so I can get the software vendor to continue taking a look at their database?
Notes:
We have SQL Server 2017.
I don't know much about SQL Server - if a solution would have complications I might be expected to be aware of in trying it, I'm afraid I really won't be aware of them they're mentioned, which is something I'm also hoping to get from an answer (if applicable). I want to make sure I do it right.
I am working on some stored procedures at a client site.
To debug stored procedures using SSMS, it seems you must be a member of the [sysadmin] group. However, they only have PROD and TEST database instances, and the DBA will not grant me these permissions.
According to him, using inline PRINT statements is considered to be just as good as the ability to debug. That doesn't seem quite right to me so I was thinking of escalating my request, but thought I'd first ask here, is this common sentiment in the industry (that the ability to debug is "not necessary")?
Though bit opinion based question but yes I have always used debug like that ... that is get the procedure body and run each code block separately to find where the problem is and fix accordingly.
You might also want to consider the execution plan of the procedure which will help in debugging.
In my experience, yes.
I once found the debugging functionality very useful when I was transitioning from being a ASP developer to a SQL developer, but as I've become more comfortable with SQL, I find that I can do all my debugging with PRINT statements.
Also in addition to being a sysadmin, did you know that you have to be running the debugger locally on the SQL server to use it? It's a lot more trouble than it's worth.
I have a client who wants to develop an application using Access 2007. For the stated short term purposes, Access 2007 fits their specification:
approx 30K master records
6 or fewer users
department file server
The issue is that the client is very technically naive and isn't at all aware of the trouble they might get into if the scope increases. The application will be storing master data that will be uploaded into an enterprise system and I fear that six months from now I'll be hearing any of the following issues:
we need to keep all of the historical data (suddenly we have 3M rows)
we need fine grained and airtight user level security
we keep getting corrupt data records
our database wasn't backed up for three months (because a user kept it open)
I've done a few small Access databases but I'm a SQL server dev by trade and I know how to use it to solve most any problem. I don't know if my client should be worried about their choice of technology - and if they should, I'm not 100% sure how best to communicate the risks to them.
I fear that six months from now I'll be hearing any of the following issues:
we need to keep all of the historical data (suddenly we have 3M
rows)
Three million rows isn't necessarily a deal-breaker for a Jet/ACE data store. Depends on amount of data in each of those rows.
we need fine grained and airtight user level security
This is a compelling reason to move data storage to client-server db.
we keep getting corrupt data records
That should almost never happen with a proper Access implementation, contrary to claims by Access bigots. It will happen if you're running across an unreliable network. But, if that's your client's situation, you should either fix the network problems or ditch Access for data storage.
our database wasn't backed up for three months (because a user kept
it open)
You can build on Arvin Meyer's KickEmOff approach. But with <= 6 users currently, it might be easier to deal with the situation without code for now. Just ask them to close out long enough for the backup. You could have your automated backup routine create a notice when its attempt fails, so this shouldn't have to be a constant thing.
In any case, suggest you design the current application so that an eventual migration to SQL Server will be less troublesome. Avoid Access-specific features: hyperlink data type; lookup fields; multi-value fields; attachment fields; and so forth. Since you're experienced with SQL Server, it should be fairly easy to create a test SQL Server database and link a copy of your Access front-end to it. Test periodically as you develop the Access front-end. Then you look like a hero when the client recognizes a need to move the data storage to SQL Server.
I'm in a mixed Sql/Access dev shop and understand your concerns, but the sheer usability of Access often wins out for users. Where we have mission critical data and need to use Access we simply used Linked tables - best of both worlds, Sql handles Security, Backups etc and Access provides the front end.
To me, the obvious answer is to develop an Access front end to an Access back end for the initial implementation, but doing the development with upsizing the back end to SQL Server in mind.
That means just applying commonsense to what you do, as #HansUp suggests (i.e., not using Access-specific functionality), and designing your data retrieval so that it will work well with a server back end.
If, on the other hand, either the increased amount of data or the security issues are actually not just remote possibilities but likely to become issues during the lifetime of the app, I'd go with a SQL Server back end from the beginning. But your description of the situation really doesn't sound like that's the case at all.
Certainly the corruption and backup concerns are completely misplaced. Proper maintenance and backup has to be in place, and the operating environment has to be stable, but all of that applies to any database engine, not just to Jet/ACE.
Explain to your client that you will have to charge much more money to create, implement, maintain, repair and later upsize the application. Explain that they will not save money in the long run and that they will be better off if they go ahead and allow you to properly prepare now. That being said, I agree with #HansUp suggestions. You can give the customer what they want and still prepare for the likely eventualities. Think of it as job security.
There are Price and GUI advantages to using Access over SQL that for the non-technical people are really attractive. I think given your scenario then maybe the "customer" is right - aren't they always!
However, your 4 "following issues" really answer your own question.
If your user is technically naive then there is not much point in using technical language. If at all possible when l speak to users the language and terms I used are the same my users understand. Also compliment your users when possible it makes them feel good and make you look good in their eyes. Here's some suggested ideas.
Using Access 2007 is an excellent idea, easy to develop with and change to met your needs. However there are a number of very strong technical reasons for using another free tool, namely SQL express to store the data.
Why use SQL express?
Its free !
Security of the data will be a very high priority (even if client has not mentioned this use this as a reason). Point out how easy it would be to steal all the data from Access compared to SQL server. See this book for excellent detail regarding Access security. The user level security for SQL server is much simpler and easier with SQL server, and will cost less money to implement, as well as being more secure.
Backing up of data. In order to back up the access database no one can be using the database or even connected to the database. With SQL server can back it up at any time. Less down time or in other words greater productivity using this other FREE tool.
Data corruption. One issue with Access database, is corruption of the database. What does this mean? It is possible to lose up to a days worth of work, with SQL server this issue is much very much less likely to occur. There are even situations where it is not possible to recover the database. Hence this loss of productivity can be minimised if using SQL server.
When this tool gains greater recognition and other departments wish to use it, as no doubt it will. Moving to a larger enterprise database system will be much easier and less costly to develop, if you use SQL server express as the data store.
The above are just suggestions, based on the assumption you user is wishing to expend as little money as possible, and the limitations / resources you put in your posting.
I also appreciate that not every one will agree with what l have put in the suggestions above. They are not meant as detailed technical points, more as suggested ways of persuading a technically naive client to consider using SQL server express as the back end db for an Access db used for a departmental application
I'm working on a business app that requires that ALL database transactions be audited (for legal purposes mainly).
I've looked around the web and came across DoddleAudit (http://www.codeplex.com/DoddleAudit) which basically adds the ability for Linq to SQL to track the changes. Much like people use Interceptors in Hibernate.
The thing that concerns me with this is the reliability issue. While an audit log on the ORM layer may record everything that happens via code, it won't log any changes if say a someone manually issues an SQL statement against the database, or a hacker etc. Basically the information I'm dealing with is somewhat sensitive. That's what leads me to believe that Triggers is probably the most reliable way. (?)
Other ways to log would be through code, or through stored procedures which seems a bit hacky and unreliable. So I'm basically down to either using triggers or something like DoddleAudit.
I was hoping to get a few opinions though before choosing either.
If the audit is for legal purposes then you have to do it through a certified for compliance methodology. Such methodologyes are very specific to the specific threats being mitigated via audit. You need to read up on Auditing (Database Engine) and more than likely consult a specialist that can give you guidance on the various legal frameworks that surround data audit, specific to your location and domain.
SQL Server has the C2 compliant audit mode, see c2 audit mode Option, which is a certified compliant mode. Linq2sql audit or custom data audit may be brilliant feats of engineering, but they're not gonna hold a drop of water if they are not certified for compliance (and they're not).
If you are using SQL Server 2008 (the question didn't specify), have you looked at the support added in that version?
http://msdn.microsoft.com/en-us/library/dd392015.aspx
I am working for a company and I need to create a program really fast. My program will run with 100 users and they will make approximately 100 transactions each per day. As I am under time pressure, and various other constraints it is not possible to set up a proper database running on a server. I am therefore looking for alternatives that have some sort of transaction support without running on a server. I believe this could be solved using Microsoft Access, which is an alright solution, though I believe I will run into locking problems. Isn't is so that a whole table is locked as soon as one user attempts to read from it? Anyways... My question is what other alternatives there are.
The real answer is likely to vary significantly depending on what quantity of data is being talked about here.
I'd take a look at SQLite. It supports transactions, triggers, etc and is supported by things like NHibernate which may make your database mapping life much easier.
Check out SQLite.
Is sqlite a proper solution? Not sure how remote storage is supported, though. That's not a common feature.
You could look into SQL CE, it's a very good local database from Microsoft.
There are many options. As others have stated, setting up and running with SQLLite, SQL Server Express, or any of a number of other small, light, and free databases.
Assuming you need this today, I would go with the one you know most about. Further, I would stay away from anything resembling Access. If you don't already have experience in using it for multi user access, you are going to burn too much time figuring out the problems.
That said, I'd lean towards SQL Server express first. It's free and can scale up to full sql server with no code changes.
I believe this could be solved using Microsoft Access, which is an alright solution, though I believe I will run into locking problems.
I'd say locking and queuing would be the least of your worries. With 100 concurrent users, Access will probably corrupt itself in minutes. With 10k+ records/day, it will likely bog down your entire network in a month or so.
As I am under time pressure, and various other constraints it is not possible to set up a proper database running on a server.
You can bring a database server up in an hour. Much less time than you'll spend hacking away at Access. There's open-source virtual machine images, MSSQL Express, hosted solutions, etc. Time and cost should be non-issues.
About the only thing I can think of that would have you using Access is the Forms support (which can be hooked to MSSQL Server) or DBA maintenance. Frankly, though, at 100 users Access will take so much babysitting that you can afford a hosted SQL instance and still come out ahead.
I think that Firebird can be a very good alternative.
Firebird is available in embedded and can also work with server. It have many features.