This question might not be perfect for this platform but I trust people here a lot.
I am coding a data transfer application for an ERP system, many people create C# projects that are slow, not flexible and full of errors. I found a way to do it in SQL SERVER with Stored Procedures. But I dont want my SPs to be stolen by any programmers since SPs are kind of open source. I create my SPs with encryption but I found a small application on the internet which can show the content of SPs.
Is there any other way of encrypting and securing my SPs in sql server?
Is your application entirely written in Stored Procedures with no other code? How likely do you think it is that someone really will want to steal your code? I only ask because usually, if someone wants the code badly enough, they will find a way to get it. If they will go so far as to counterfeit an entire Apple store then someone can always crack any encryption scheme.
The best way to protect your intellectual property (i.e. the code) is to simply not give it to anyone: host it as a service. Outside of that obvious, simple, yet not always possible option, here are some things to consider:
For T-SQL stored procedures you can certainly deter the lower-end thieves by using the built-in encryption. Yes, you found a way to decrypt it by searching around, but not everyone will do that or know what to look for. This is not much of a barrier, but again, it is a very easy step that weeds out folks who are just poking around.
You can put some of your code into SQLCLR (i.e. .NET C# or VB via SQL Server's "CLR Integration" feature/API), though this won't work for everything, nor would it be a good choice to do for everything. But, for any code that would be more efficient to do in SQLCLR then it would be even harder to get the source code of the Assemblies. Again, not impossible, and there are free tools out there to decompile Assemblies, but this does raise the bar a bit as someone would have to extract the Assembly to a DLL and then decompile it (though I believe one tool will extract it from SQL Server, but still harder to come by than "how to decrypt an encrypted Stored Procedure"
With regards to .NET code (definitely for stand-alone app and possibly also for SQLCLR code), it is also possible to obfuscate the Assemblies such that it is very difficult, at best, to decompile it. There are products such as Red-Gate's SmartAssembly that can do this.
Be better than your competition:
Innovate and offer better features (i.e. a better product). Listen to customers and make their lives easier. Even if someone does end up getting your code, they can't steal you. Stolen code might teach them something, but it is essentially stagnant compared to what you should be producing.
Offer better service. Be personable and answer questions thoroughly, respectfully, and with a smile (even silly / stupid questions--if you need to, vent to a friend, but never in writing). Sure, some customers decide to purchase purely on price, but service/support is usually a large factor in both getting and retaining customers.
So, if you can find a quick and easy means of doing this then great. But don't spend too much time on it when your time is better spent improving your product. Besides, unless you came up with some highly complex algorithm, most things can be reverse-engineered, if they are smart enough. But if the folks you are worried about were that smart, would their software be "slow, not flexible and full of errors"? And along those same lines, (and just to have it stated), the other software being "slow, not flexible and full of errors" has nothing to do with them being written in C# (especially not the "not flexible and full of errors" issues): they simply just aren't written well ;-).
Yes there is a way, simply use the option WITH ENCRYPTION in your sp's definition.
Example
CREATE PROCEDURE spEncryptedProc
WITH ENCRYPTION
AS
BEGIN
SELECT 1
END
GO
Now try to see the definition of that procedure.....
exec sp_helptext 'spEncryptedProc'
Result: The text for object 'spEncryptedProc' is encrypted.
Make sure you personally have a copy of the stored procedure saved somewhere else you cannot see the procedure definition yourself.
Related
I'm creating a windows form app and the underlying code needs to be secure. In the code is database information and many equations which people should not be able to see.
What I'm asking is if I install the app on someone's computer, how easy is it for them to "break" into the application and view this sensitive information? If it's not difficult for them to find the code, are there ways to prevent this from happening? I would appreciate any input.
It's very easy to view code. Tools like ILSpy or .NET Reflector can practically show your code as you have written it in C# or VB.NET.
There are some possibilities, some free or cheap, some will cost you:
Obfuscation: This replaces names and sometimes logic in your excutable with other code that is hardly human readable. This is easy to do and there are tools like Confuser that do a good job, but the code is still there and can be read. It's only slowing attackers down.
Another option that I have evaluated myself is using hardware protection in the form of Dongles. Here the whole application is encrypted with a secret key that is stored on a smartcard. Portions of the code that are needed are decrypted on the fly at runtime and executed. Since the code is encrypted you can't read it easily. Solutions like Codemeter are pretty hard to beat (there are no real cracks for these if implemented correctly, which isn't hard. But this is not for free.
You always need to have the scope of your protection in mind. Who do you want to keep from getting your code?
The average guy who also has used .NET some times and knows how to google and download ILSpy? Obfuscate it mildly and he will be annoyed enough to leave it be.
Some other people who really know what they are doing but still without financial interest? Use some more drastic obfuscation like code restructuring and so on and they will probably not invest weeks of their time to just finding some formulas.
Some other company who is willing to put in the financial ressources and the knowhow of talented people to get your code to make a profit? Obfuscation will not help you. Maybe encryption will, maybe not.
We went with the Dongle solution since we also want to manage licensing in an easy way for the customers (of which most have very restricted online capabilities), while the code protection is a very nice additional feature.
You can use two-way cryptography before storing the information on the database. This question's answer has an explanation of how to do that very simply: Simple insecure two-way "obfuscation" for C#
About the equations, if they're hardcode in your app, and you don't deliver the source code of the app, the only way to retrieve it is using disassembly, wich, even with very simple tools, you have to be "computer savy" to do it.
This stems from an earlier SO question.
If you are having to perform actions on the file system are you usually better off writing an application to handle those actions and making calls to SQL Server from that app? In what situations is using xp_cmdshell a good idea?
It is just another tool to be used. As with all tools, use it when it fits. Some people may have very strong opinions one way or another, but at the end of the day, it is there.
SQL Server 2005 introduced sp_xp_cmdshell_proxy_account which alleviates the issue somewhat with privileges, so it becomes more useful.
Consider the powder-key question: Is it generally bad to allow people to carry guns (guns being dangerous being the correlation)? Cue arguments...
When dealing with 3rd party apps where you don't have access to their source code, SQL Server may be the only or at least the most convenient place to put the logic needing access to the file system. Creating another app is just one more thing to worry about.
Security does become an issue. Additional privilages can be made available to users. http://msdn.microsoft.com/en-us/library/ms175046.aspx
In 2002 I did a pretty large VB6 app for a client. It used a lot of UserControls and a 3rd party menu control (for putting icons next to menu names). It had dynamically "splittable" panels, TreeViews with multi-state checkboxes, etc. A very rich UI. My total time on the project was about 500 hours, which the client graciously let me spread over a whole month. (Yeah, it was that kind of job.) They were very happy, though, and they paid the bill on time with no argument.
So after having no contact with them for years, they suddenly call and wonder if I can update the app to .Net for them. My initial reaction is just to decline, since I don't use VB.Net. And having read a bunch of posts on SO about the difficulties of porting, etc., etc., I'm even more inclined to decline, so to speak.
Still, before I tell them no I am interested in roughly quantifying the effort it would take. I would love to hear from anyone who has done this kind of thing and has a feel for how much work it is. Was it:
Significantly less than the effort you used on the original?
Somewhat less than the effort you used on the original?
The same as the effort you used on the original?
More?
A lot more?
Please only respond if you have actually done this kind of port. And the answer doesn't have to be exact, since I really am only trying to ballpark this. My feeling is that the effort will be at least as much as it took for the original, if not more. But I could be wrong. Thanks for any help.
I have done what you've been asked. In my case it was an (amateur) bowling tournament mgmt system: Member database mgmt (personal info, IRS/Winnings info, mailing lists etc etc etc) , tournament mgmt (player assignments, scoring, lane ticket generation, check register for winnings and side-pots, etc etc etc) as well as IRS EDI generation for all winners in a given year. Plus about a billion little items scattered across ~ 50 screens/sub-screens.
The key is CLIENT UNDERSTANDING -- You must be clear that they understand that this is not trivial; this is a new adventure for BOTH of you (particularly if you are a new-comer to VB.Net) If they liked your work before then they may very well give you the leeway/freedom to learn VB.Net on their nickel.
Reading some of the previous answers let me make a few suggestions (based upon 30 years experience as a software developer, the last 20 of which as a consultant....)
TAKE THEIR MONEY IF THEY OFFER IT. You need to bring your skillset into the 20th century; let them pay for it (again, if they agree.) They may be Magazine surfing and want "the latest stuff" for NO GOOD REASON -- but maybe they realize that they can extend the life of (your) application by this port. In essence they may have all kinds of goofy reasons for doing it... if they are NOT hiring you to DECIDE whether or not this port is a good idea. Then you may express any dismay you have about the decision PROCESS out of good client relationship building; BUT if they want to do this then it might as well be your job.
Take all this mumbo-jumbo re: C# vs VB.Net with a grain of salt. I have worked EXCLUSIVELY in VB.Net / ASPX.net (vs C#) since its inception and have yet to come across ANY functionality NOT attainable in VB.Net. There are some 'purists' out there that just view VB.Net as a toy. Well, I came from the days of writing in Assembler, then C, then C++ (And you can throw in Fortran, PL1 for good measure) then VB5, then 6, then VB.Net ... and NOW JAVA for Android. Its ALL GOOD FUN... and each has it merits and drawbacks. Remember that C# and VB.Net are essentially just GUIs to achieve a meta-language intermediate. You can write a TERRIBLE (as measured by efficiency or memory use or whatever metric you choose!) Program in C# and a great one in VB.Net (and vice-versa.) DO NOT EQUATE GOOD PROGRAMMING WITH LANGUAGE SYNTAX. (... C# is "superior" ???? Gimme a break.)
I chose to allow the Visual Studio do most of the heavy lifting for the first pass. Then you go through the gazzillion errors and clean it up. It goes pretty fast.
BUT you need to decide whether or not to take advantage of any framework benefits that you had hand-coded in VB6. E.G. looping through a string to locate a specific character(s) is now as simple as The_String.IndexOf("c") I found that in my case I went through the code several times and took better and better advantage of the Class (i.e. object orientation) as well as framework goodies as I became comfortable... this adds to your development time (see CLIENT UNDERSTANDING mantra) BUT your code WILL BE MORE Efficient then it ever could have been in VB6. You could simply port to get the errors out and not take ANY advantage necessarily from the framework.
I have not found any issue with 3rd party active-x controls. You can add a reference to FRAMEWORK objects, COM objects, etc. It may even be likely that the control vendor has a .Net (managed code) version... OR there may be suitable alternatives since you wrote the thing in VB6. (See CLIENT UNDERSTANDING mantra)
So if your still reading, then now I will finally tell you that the second attempt at my application in VB.Net CONVERTED/PORTED from VB6 was ~ 1/3 of the original time to get to a working model... and I was learning the framework as well. (If your confident in your skill set, have learned a few languages through the years you will get the gist of VB.Net quickly --- its the SUBTLETIES that take awhile.)
I must caution you that the thing that can REALLY kill you if you do not preach the CLIENT UNDERSTANDING well enough is if they want to make changes WHILE you're porting (and this is VERY LIKELY since they've been using it for awhile... I was very true in my case as well.
There is no hard and fast rule here. It could be that changes will actually HELP YOU get to a better understanding the framework faster OR changes could be a real pain. Only you can determine which flavor they might be. AND if they look to be the PAINFUL type -- you might ask to do the conversion first so that you have reliably reproduced the functionality -- THEN go back and review the code to make changes and take advantage of the framework as necessary. But, as I said, there is NO Hard and Fast rules here -- and don't let the purists tell you differently --- remember they are probably the same guys that said that PASCAL was going to take over the world!
So after having no contact with them for years, they suddenly call and wonder if I can update the app to .Net for them.
You need to ask why they want this done.
It's a Bad Plan(tm) for clients to be making technical decisions on a whim. Before applying any solution, thoroughly understand their needs and their problem. Only after you understand the problem as they do should you make recommendations.
It could be that they're infatuated with a buzzword and want to be using the latest thing, or it could be any of a million other things. The solution to their problem could be something really easy, but if you don't find out what their problem is, you will never know the best way to solve that problem.
I would plan on it taking about 50% of the time and effort it took to create it in the first place.
I have done EXACTLY what you are asking about for a commercial software product that consisted of roughly 500 kloc. We balanced the desire for refactoring with the desire to get something working and released as quickly as possible.
It took nearly the entire team about 1 full year to get it done...for a product that took 4 years to create in the first place. It was a gigantic undertaking..not to be underestimated.
We are doing that exact thing right now, however it's slightly different. Instead of one huge application, there are many smaller ones. However, there are a few bigger ones in the list. What we found out is that it was significantly less work than we originally thought. BUT...the biggest unknowns had to do with third-party controls we had. If you have a lot of those to basically redesign, you will probably be looking at more work.
The one good suggestion I have is to use Visual Studio 2008 for the conversion (not VS 2005). There were far less problems when using the built-in converter in VS 2008 than there was with VS 2005. Not sure why, it just was that way.
So, I can't say that you won't spend 500 hours again, but most likely not. Most of your time should be spent on testing to verify no functionality was lost.
In my opinion,
Visual Basic 6 and Visual Basic .NET are so different that you should forget about their coincidence in their name, and treat this as a migration to .NET =P
I think that you have one big advantage and one disadvantage:
Advantage: you allready know what the application has to do. Probably you´ll have some meetings with your clients, in order to add some modifications or new features, but you have the major part of the requirements very clear. You´ll even have the old working application to see while you, or your team, are coding.
Disadvantage: you´ll have to learn a new language. Saying how much time is going to take, is very subjective. I´ve allways thought that learning a new language is not the problem, the big problem would be if you have to learn to program!. But you do know to program. You´ll know what you want to do, and you´ll have only to search how to do it in the new languaje.
Since you have to learn .NET, If you have to estimate, I think that you should suppose that it will take you at least the same as the previous application, even more.
My advice is too take the chance to learn this new language. And if you are more inclined to decline the project, let me give you another idea... Maybe you could estimate a little module of your application, and tell the client that you´ll try to do that module, to see how much it takes to you. The client should pay this little module, even if you decide not to continue.
You can´t tell the client that you know all the requirements, so they are saving money with you, in some way. And that they should take this little risk (we are talking about a little module), because who better than you to make the project, you know the old application perfectly!
If the client is right with this, you´ll can take the decision with more arguments. And If finally you decide to continue, with this little module done, you can estimate the whole project better than before.
Sorry, my English isn´t very good, and probably I´ve made many gramatical errors.
EDIT grammar mistakes... =P
This is a huge topic.
You should take a look at MS' Free Book - Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET.
Were you to rewrite from scratch, rather than simply try and port the previous application, it shouldn't take too long. VB.Net has some features that will make the new application build take shorter. As it seems that you don't know VB.Net already, what will take you the most time is learn how to do things the new way(tm).
I'd go for two months this time.
But seriously, that's probably not far off — or even low — because the client will have some reason for needing the port done. It won't be just a straight port - they'll want some "small little enhancement" that will blow the whole project up.
Additionally, I'd worry a bit about the third party controls. Most of the rest of it should convert okay, but there's sometimes an issue finding a good analog to a 3rd party control in .Net.
I'm also concerned that you don't use vb.net. If you're a c# user and wanted to re-implement that way you'd be fine, but otherwise this is a non-starter. VB.Net is just different enough from vb6 for you to get yourself into trouble.
Aside from all that, I would expect it to be less work this time than last, because you have a very explicit design laid out in front of you that you merely need to follow.
For starters I should let you guys know what I'm trying to do. The project I'm working on has a requirement that requires a custom scripting system to be built. This will be used by non-programmers who are using the application and should be as close to natural language as possible. An example would be if the user needs to run a custom simulation and plot the output, the code they would write would need to look like
variable input1 is 10;
variable input2 is 20;
variable value1 is AVERAGE(input1, input2);
variable condition1 is true;
if condition1 then PLOT(value1);
Might not make a lot of sense, but its just an example. AVERAGE and PLOT are functions we'd like to define, they shouldn't be allowed to change them or really even see how they work. Is something like this possible with DLR? If not what other options would we have(start with ANTRL to define the grammar and then move on?)? In the future this may need to run using XBAP and WPF too, so this is also something we need to consider, but haven't seen much if anything on dlr & xbap. Thanks, and hopefully this all makes sense.
Lua is not an option as it is to different from what they are already accustomed to.
Ralf, its going to reactive, and to be honest the timeframe for when the results should get back to the user may be 1/100 of a second all the way up to 2 weeks or a month(very complex mathematical functions).
Basically they already have a system they purchased that does some of what they need, and included a custom scripting language that does what I mentioned above and they don't want to have to learn a new one, they basically just want us to copy it and add functionality. I think I'll just start with ANTRL and go from there.
Lua
it's small, fast, easy to embed, portable, extensible, and fun!
Lua is definitly the best choice for soft real-time system (like computer games).
See http://shootout.alioth.debian.org/ for detailed benchmarks.
However, last time I checked, Lua used a mark-and-sweep garbage collector which can lead to deadline-violation and non-deterministic jitter in real-time systems.
I believe that you could use theoretically use the DLR, but I'm unsure about support in an XBAP (partially trusted?) scenario.
If you host the DLR you would quickly be able to take advantage of IronRuby or IronPython scripting. You would want to look at these implementations when creating your own language implementation. If you post your question to the IronPython mailing list I'm sure you would get a better reply around the XBAP scenario, and some of the developers there created ToyScript.
What kind of real-time requirement are you trying to fulfill? Is the simulation a hard real-time simulation (some kind of hardware-in-the-loop simulation ==> deadline is less than 1/1000 second)?
Or do you want the scripting-system to be "reactive" to user-input ==> 1/10 should be sufficient.
I am no expert regarding MS DLR, but as far as I know, it does not support hard real-time systems. You may want to take a look at the real-time specification for Java (RTSJ)
Firstly I think that defining your own language is not the way to go.
Primarily because the biggest productivity gains you can get for programmers or non-programmers are the development tools. You (and 99.9% of the rest of us) are not going to write tools as good as what is out their.
Language design is hard.
Language support and documentation, also hard
I would recommend looking for a pre-built solution. If you could find a language that can lock down some functionality, that would be a good starting point. MatLab would be the first that comes to my mind.
Lastly, ditch the natural language part, BASIC, COBOL and YA-TDWTF-Lang all tried and failed at it.
Full disclosure: I work for a company that is developing a generalized domain specific language "system". It's targeted at data-in/text-out applications so it's not apropos and it's not yet to beta. The result is I'm somewhat knowledgeable and biased.
Wizards can kick-start features. They can also obfuscate your code, and are anti-YAGNI.
On balance, do you think Wizards are more useful or more harmful?
They are more useful than harmful if and only if you understand the code they generate.
Only after you mastered the problem the wizard is trying to solve they are really useful.
Otherwise you'll hit walls later in the project, because the generated code will need modifications at some point.
"The Law of Leaky Abstractions" really nails it on the head.
They're there for a reason - to try and make your life easier.
They can be useful and save you 5 or 10 minutes of typing. Of course it's best to read and make sure you understand what they've written for you.
If you use them without understanding, then they could be considered harmful in the fact that they're letting you get away with not learning something you should probably know, but on balance I think they're a good thing.
Wizards are good if and only if you can get away with never editing the code that they generate. In that situation, they are in essence a very high level programming language. When you change your mind about something that was generated by the wizard, you can run the wizard again.
Wizards are most horribly evil if you must ever edit the code that they generate. If you do this, and later change your mind about one of the choices that you made in the wizard, then you are forced to choose between two very bad options. You can rerun the wizard, and reapply the manual edits, or you can try to edit the multiple copies of the boilerplate code that the wizard created the first time around. In the former case, you are likely to forget at least one of your edits, and in the latter case, you are likely to miss at least one of the places in the code that was affected by your choice at wizard running time.
Wizards are "mostly harmless" when they generate an encapsulated entity - a function, a class or a set of classes - which you don't need to modify and which you interact with through a well-defined, well-designed interface.
On the other end of the spectrum is a wizard that that generates skeleton code that needs to be extended and modified. This is especially troublesome if you can't change some of the wizard option later without losing your edits.
These are still "ok" for the pro who could write the same code by himself and uses the wizard to save time. However, when they are used to make something complicated look easy for beginners, they are a paint job over a rusty car: they help selling something that you otherwise wouldn't buy.
In practice, they may still be useful to ease adoption of a platform. But that's a business aspect, and whether business aspects may justify code blunders is a question of the development environment.