InstantForum.NET v4.1.4SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 18 Mar 2010 10:58:10 GMT20http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxEncrypting the stored procedures is something that I have been looking forward to implement on our products, unfortunately with SQL Server, it is really no point in doing so as most of us already aware that you can easily decrypt them. I do agree that it is still the first level of protection, but until versioning is possible in SQL Server. Otherwise this will add burden to the person doing the support. In my wish-list, I am looking forward toward a “versioned” encrypt able procedures. As in most products, each of customers may implement a different version of procedures; therefore it is important for the support person knowing what they are troubleshooting. Yes, it adds complexity in troubleshooting but it is another form of protecting the codes from direct competitors nowadays.Mon, 13 Apr 2009 16:01:33 GMTpeter_wonghttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]michael.wiles (4/13/2009)[/b][hr]For me, the consideration to encrypt anything at the database level comes down to who owns the data. Certain information a client should have access to while other areas they shouldn't. Any information that I personally enter into the program I should have access to see and manipulate for my own purposes. Addresses and contacts would be a great example of this. By encrypting everything, you are forcing the user to have to enter their address information in all over again even if that information exists in another source. By allowing them to have access to it, they can write their own import routines even though you haven't explicitly defined that functioanlity in code. Likewise, any information that is considered proprietary the user should not be able to see. For example, as other posts mentioned, company IP addresses, database usernames/passwords, smtp address information or any information stored in tables that are considered proprietary information. As a developer, I know often times when I'm using a program, I state to myself I wish that the program could just do XYZ. By letting me have access to my own information and non proprietary information, I can implement those changes myself, which may actually keep me using the prroduct to begin with. If I wasn't able to make some minor changes, then I'd probably switch software packaages to find the feature.[/quote]If the database you are referring to doesn't have a real application with real auditing and business rules, then YES you should/could be able to do whatever you want to the data. If it is a mission critical database with a real app and real business rules with some sort of audit trail as to who made changes, when, and under the business rules, then NO you shouldn't have that kind of access to it even if it is your data. This may be over simplified, but just something to think about. I have gotten many requests over the yrs to do "data fixes" and very early on I recognized the value of pushing back pretty hard on these explaining to users, managers, directors that if I do the data fix, they lose all auditability of those changes (if it was present in the first place).Mon, 13 Apr 2009 12:08:30 GMThfxDBAhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxFor me, the consideration to encrypt anything at the database level comes down to who owns the data. Certain information a client should have access to while other areas they shouldn't. Any information that I personally enter into the program I should have access to see and manipulate for my own purposes. Addresses and contacts would be a great example of this. By encrypting everything, you are forcing the user to have to enter their address information in all over again even if that information exists in another source. By allowing them to have access to it, they can write their own import routines even though you haven't explicitly defined that functioanlity in code. Likewise, any information that is considered proprietary the user should not be able to see. For example, as other posts mentioned, company IP addresses, database usernames/passwords, smtp address information or any information stored in tables that are considered proprietary information. As a developer, I know often times when I'm using a program, I state to myself I wish that the program could just do XYZ. By letting me have access to my own information and non proprietary information, I can implement those changes myself, which may actually keep me using the prroduct to begin with. If I wasn't able to make some minor changes, then I'd probably switch software packaages to find the feature.Mon, 13 Apr 2009 11:56:36 GMTmichael.wileshttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxMy company has a goverment contract and must meet the DIACAP(DOD Information Assurance Certification and Acreditation Process) standards. These require that all non-vendor stored procedures and views must be encrypted. So, some times, you have no choice in the matter.Mon, 13 Apr 2009 10:47:33 GMTBrian Brown-204626http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI'm not sure encryption ever protects IP. If the computer needs to execute it, someone can decompile it. Those rules are well understood, and IP protection is usually through the legal system.Mon, 13 Apr 2009 10:22:50 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI wish the encryption worked. The current implementation is a joke and as such is useless. I think there are many cases when one would like or must encrypt the code.Most of mine applications have 80% to 90% of their business logic in the database so having the stored procedures encrypted would greatly help if I wanted the IP protected. In my opinion the problem is not why you need it but why it is implemented in such a way that any smart kid can brake it in 5 minutes.Mon, 13 Apr 2009 08:09:42 GMTJacekOhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxJohn,I think you might have hit the exception that proves the rule. Slowing someone down in that case might be a good use for encryption, or it might not be. The code in 2000 can be broken very quickly with modern hardware.Mon, 13 Apr 2009 07:33:42 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]Mark Horninger (4/13/2009)[/b][hr]Steve,I did some work a while back where this was a concern - the issue was less in them stealing the code and more aorund supporting something they botched up.Answer was if they touched it the warranty was null and void. After about 2 mos something stopped working and they wanted help, used RedGate to compare with what we gave em, found the changes and called them on it - ended up fixing it at time and materials, but redgate saved us some $$$ and aggrevation!Turned out one of thier employees messed something up in a couple of sprocs.Mark[/quote]SQL Compare (and other like products) is definitely a lifesaver. We had a similar issue with a developer. They would send us scripts for the QA environment then for production. At some point it got out of sync and they and our own developers could not figure it out. Enter SQL Compare, and it proved that they had sent us an incorrect version of the production environment.In the long run, this may be the most doable way to insure your code, as a developer, has not changed.GabyMon, 13 Apr 2009 07:10:05 GMTGabyYYZhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxSo what does the edge of the coin have to do with encryption? It would seem nothing at all, other than to consider that the chances of getting the edge are slim to none for most situations and people. It is only when the conditions are such that even the slightest chance for compromise of a database system is cause for alarm that you really should think about it. Most people here talk about systems that are written to be used by other customers on the customers own systems and ran by the customers own IT staff. The programmers will want to protect their logic a bit to either hide their shortcomings or to keep others from taking their brilliance. Others just don't want the customer to be sticking their nose and sticky keyboards into places they don't belong. In most of these cases, what is the primary thing that is lost if the customer does get into the database? Money. Some companies write their code to be ran on their own systems or to be ran by a customer on a dedicated system that must do one thing - work good. For this, there is little need to worry about the customer getting into your code. The higher concern now is the outsider that should not be there in the first place, commonly called a hacker. This person actually can be a problem to consider in the previous paragraph too. But in the end, what must be considered is what could be lost if a hacker did get into the system. What are you trying to protect? In most cases, the end result is still money. One person did show that there is a case when all possible attempts to protect the data must be taken. This could be done with encryption of the data, encryption of the stored procedures, generalized naming of tables and columns, etc. What could be so valuable that it is worth to do all you can and even consider the most remote chances possible (the edge of the coin)? How about when the final cost of data compromise may not be counted in money, but be counted in human lives? Where the hackers trying to get into your system are not just some smart kids having some fun but somebody who is determined to find out any weakness and exploit it in a most deadly way. I do agree that too many companies and too many people inflate the importance of their code and the importance of their data to justify their extreme encryption efforts. But for some situations, enough just isn't enough. The cost of data compromise through code or data itself is just too high.Mon, 13 Apr 2009 07:05:56 GMTterrance.steadmanhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxSteve,I did some work a while back where this was a concern - the issue was less in them stealing the code and more aorund supporting something they botched up.Answer was if they touched it the warranty was null and void. After about 2 mos something stopped working and they wanted help, used RedGate to compare with what we gave em, found the changes and called them on it - ended up fixing it at time and materials, but redgate saved us some $$$ and aggrevation!Turned out one of thier employees messed something up in a couple of sprocs.MarkMon, 13 Apr 2009 07:01:21 GMTSuperDBA-207096http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxThis is a topic I have been struggling with at my new job with a software company that hasn't exactly had a DBA before and works very hard to please ALL of its clients (impossible I know, and I am working on changing that culture). Our customers are typically very small health care agencies with limited to NO real IT staff. Anyway...I don't think encryption/obfustication does the product any good and will not server clients well in the end. As software vendors we want to create and deliver a good product, but in the end we want the customer to own his environment and be aware of good database practices like backups, index maintenance, predicting space requirements, etc. etc. In order for the customer's DBA to be aware of indexing needs and in turn the performance of their environment, I feel they need the ability to see what they need to index and to become a little familiar with the SP at least. Data evolves, so indexing needs to be revisited (at least). I 100% am against customers changing any stored procedure, but I have nothing against them seeing the code (as long as the proper legal documents are in place for the proprietary knowledge, etc). I am always open to constructive criticism whether it come from a colleague or a customer.I am simplifying this next part, but you get the gist...The thing I do to ensure we don't end up with a support nightmare because the customer 'tweaked" soemthing in the database is to schema compare and hash compare SP what we delivered against what the customer currently has first. If that checks out, we continue... If it doesn't check out, we stop and will usually offer to assist at professional services rate and make it known that current support agreements are not valid until the schemas and SP are sorted out (at professional services costs).You need to trust your relationship with your customer and if your sales team does a good job up front and describes expectations and consequences, you have a solid procedure for support and know your own schemas, yuor support issues should be kept to real support issues.Mon, 13 Apr 2009 06:39:47 GMThfxDBAhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxHere's a better solution. Have the developer send you the code in identifiable releases (4.1, 4.2, etc.). Have the pertinent block of code/query/etc. prefaced with something like [i]-- DO NOT MODIFY, V 4.2 STABLE --[/i] and close the block with something like [i]-- V 4.2 STABLE END --[/i]. The developer can hash/checksum that block of code, and both the developer and DBA are happy.The Developer can verify his code is the same by comparing checksums later on, but the DBA can examine it and figure out if something, say a RBAR, is responsible for the slow execution.It's not foolproof, but transparency and trust are maintained to a certain extent. As long as the DBA has a record of the checksums/hashes on file, he or she can be sure the developer isn't trying to pull a fast one saying the code was changed.Mon, 13 Apr 2009 06:10:42 GMTGabyYYZhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxThis is an interesting thread, but you all seem to work on commercial project. Let's say your system is tracking the location of solders on the field of battle. Of course, you will have have layers of secuirty to prevent the other sidefrom hacking into the system. You might consider encrypting the data, code, table names, columns names just to make it more difficult for the hacker. Yes, he is already in the system, but you want to slow him down, so the auditing tools detect him (her) before your guys in the field are targeted. I work on communication applications sold to the US military and they require that we encrypt the stored procedures. They also require a great number of other secuirty checks and settings. Look into the SQL security requirements of the DOD's gold disk. You think your systems are secure, just check out the public version of gold disk and find out for sure.Sat, 11 Apr 2009 16:57:47 GMTJohn LeBrunhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI think that the general consensus is that this doesnt' really provide a lot of security, and it's a pain.If you think it reduces CS calls, you're probably looking at the problem the wrong way.If you think your IP is being protected, you're in denial, in a couple ways. Your IP isn't that great, and it's not. Those that would steal the IP can get the code.Sat, 11 Apr 2009 07:37:17 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]terrance.steadman (4/10/2009)[/b][hr][quote]AndyD (4/10/2009)The quantum guys say there is no way to predict the flip of a coin. Einstein would argue there is. IFF you knew all of the forces and assumptions, you could predict the result. I interpret that as saying, we simply don't have enough information, yet.I think it is a little more interesting than this. The Quantum Guy says the coin is both heads and tails at the same time; only when someone looks at the coin does it change from an indeterminate state to either heads or tails.Now, how does this relate to encrypting our SQL code? hmm...[/quote]This is a little 2 sided now isn't it? Just to add a bit of Oh No's to this, we do live in a 3D world, not a 2D world. So, a coin *technically* does have a third option other than heads or tails. It also has an edge side. It just happens to be the rarest option to be hit, but still it is possible.[/quote]Yes, I would also like to ask what this has to do with encrypting SQL code? Now, I have to add that I never heard someone say when asked: "Heads or tails?" "Oh no, I'll choose the edge."Fri, 10 Apr 2009 22:55:27 GMTManie Versterhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]Jack Corbett (4/10/2009)[/b]This is one of my favorite things. That and the accountants not locking their PC's when they go to meetings or lunch.[/quote]This is only a problem when they also have the spreadsheet with all the financial information for the company open also - but, of course they want all that data encrypted :w00t:Fri, 10 Apr 2009 21:40:04 GMTJeffrey Williams-493691http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]stevet (4/10/2009)[/b][hr]This from the same guy that made the windows login password scheme so complex that users are putting their passwords on post-it notes on their monitors so that they can remember them.[/quote]This is one of my favorite things. That and the accountants not locking their PC's when they go to meetings or lunch.Fri, 10 Apr 2009 20:27:31 GMTJack Corbetthttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx:-DFri, 10 Apr 2009 15:23:44 GMTstevet-1034619http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxThe best advice I ever got about encryption was this: "fvlsdbjawdygexdvnsdfyeqrmcnbsdfsdofglkfbnsdkfasgsfd;zdjfhasdsjbc":-DFri, 10 Apr 2009 14:52:20 GMTBob Abernethyhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxIt kind of reminds me of several systems I've looked at that try to protect their "IP" by naming tables and columns like tbl1.col12 and not using any declarative integrity. Again, annoying and not just pointless, but downright stupid. I agree with Steve, when it comes to database design, there is no real IP involved and anytime someone thinks they've come up with some new spiffy way of doing things, it always turns out to be a rehash of a bad idea.Fri, 10 Apr 2009 14:43:31 GMTDCPetersonhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx"Encryption besides being annoying and pointless, it can also be dangerous if you lose the source code (a malicious attack by a disgruntled employee about to leave). Also I always thought that there must be some performance overhead of encryption/decryption"- Quote from athurgarI am in full agreement with this! Chance of increasing your workload and potential dangers totally outweigh any possible benefit.Fri, 10 Apr 2009 14:34:08 GMTcrookjhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]Michael Valentine Jones (4/10/2009)[/b][hr]The only time I have seen SQL Server procedure encryption used was for a vendor product.I decrypted and looked at a few of the procedures. They appeared to have been written by very unskilled developers, so I would say in their case that encryption was used to try to hide what crap they were selling. There was certainly nothing that they had to worry about me stealing.[/quote]No, but they had a lot to worry about you telling them how messed up their code is. In most cases I have seen, the object of encrypting SQL code is to hide how bad the code really is - and, in some cases to make sure the company has a revenue stream available for fixing their own broken code.Fri, 10 Apr 2009 11:23:47 GMTJeffrey Williams-493691http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI agree with Jack Corbett that if the intent is to secure IP, then leave your logic in your code. I have been mainly a developer for the past 20 years and after 10 years of part-time administering databases, I'm now taking on full DBA duties. There is an inherent paranoia with developers that everyone is going to steal your code. The fact is, if they want it, they will get it and if you hide it, people will think you're hiding something worth stealing. Leave your logic in the app, compile the app and leave the rest alone. There's an IT manager here that was really pushing me to encrypt usernames for a web app - citing that because information is saved in a cookie on the client side, someone could hack their computer and find their username for the app. This from the same guy that made the windows login password scheme so complex that users are putting their passwords on post-it notes on their monitors so that they can remember them. I think it's real easy to go too far on the encryption/security bit until the benefits become blurry.I get the support point of view, but problem users are going to tamper no matter what. I think security should be approached from keeping outside hackers from getting in and not keeping customers, users, developers, etc. out. There are enough things to worry about...Just my .02Fri, 10 Apr 2009 10:44:20 GMTstevet-1034619http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxAs a software vendor, let me tell you that what we are talking about here is not encrypting at all, just obfuscation. In order for code to run it must be decrypted. For it to be decrypted the key to decrypt must be included. That defeats the very purpose of encryption. Compiling MAY help in hiding your code as it is mostly a one way process, but the value of encryption in hiding your source code is zero and is just a nuisance. Now if there was a compile sql code option it would have helped both to hide code and to make it run faster but merely obfuscating is of no help at all.Fri, 10 Apr 2009 10:22:21 GMTumailedithttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]Theunis Viljoen (4/10/2009)...We are currently looking at encryption tools such as SQL Shield 4 as an effective encryption tool for SQL 2005. I would be interested to read any feedback on such tools....[/quote]We are using an earlier version of xp_crypt/SQL Shield (not my idea!) in an internal application to protect code used to encrypt and decrypt sensitive data and I find it to be very annoying. Every time we apply a SQL Server service pack or move a database to another server, we have to reapply all the encrypted source code. I have also found their support to be much less than what is required for an important piece of software that is critical for an application.Given this, I would automatically reject any vendor software that required the use of xp_crypt/SQL Shield.Fri, 10 Apr 2009 09:34:44 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx"WITH ENCRYPTION" should properly be called "WITH OBFUSCATION". It is a pretty simple XOR decryption routine to reverse the function and stored procedure "encryption" feature of SQL Server. This was true for SQL 7, 2000, and 2005. I imagine it hasn't changed for SQL 2008. In fact, SQL 2008 BOL says this about the WITH ENCRYPTION clause: "Indicates that SQL Server will convert the original text of the CREATE PROCEDURE statement to an obfuscated format." In SQL 2000 you needed to have SA level permissions to reverse the WITH ENCRYPTION obfuscation. In SQL 2005 I was not able to do it unless I could log in with the DAC and access a true system table. So it is a little more difficult to reverse it in SQL 2005 (and presumably SQL 2008).Regarding SQL CLR, it is compiled .NET code and is quite easily reversed if you haven't used some sort of obfuscation routine. I found that DotFuscator Professional product did a fairly decent job of obfuscating the SQL CLR code. I knew what the code was and was not able to reverse it back.Fri, 10 Apr 2009 09:28:22 GMTdrnetworkhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxThe only time I have seen SQL Server procedure encryption used was for a vendor product.I decrypted and looked at a few of the procedures. They appeared to have been written by very unskilled developers, so I would say in their case that encryption was used to try to hide what crap they were selling. There was certainly nothing that they had to worry about me stealing.Fri, 10 Apr 2009 09:25:20 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxA few thoughts from a simple-minded DBA with near fatal deficiencies of caffeine at the moment.1. Anybody that purchases an application accepts a software licensing agreement, which typically includes a clause like "you can't repackage this code and sell it." Stealing code to resell is seriously stupid and I have to believe most companies will not risk it.2. Encrypting stored procedure code, in my experience, has been more harm than good.Fri, 10 Apr 2009 08:46:52 GMTKen Klaft-381933http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote]AndyD (4/10/2009)The quantum guys say there is no way to predict the flip of a coin. Einstein would argue there is. IFF you knew all of the forces and assumptions, you could predict the result. I interpret that as saying, we simply don't have enough information, yet.I think it is a little more interesting than this. The Quantum Guy says the coin is both heads and tails at the same time; only when someone looks at the coin does it change from an indeterminate state to either heads or tails.Now, how does this relate to encrypting our SQL code? hmm...[/quote]This is a little 2 sided now isn't it? Just to add a bit of Oh No's to this, we do live in a 3D world, not a 2D world. So, a coin *technically* does have a third option other than heads or tails. It also has an edge side. It just happens to be the rarest option to be hit, but still it is possible.Fri, 10 Apr 2009 08:33:57 GMTterrance.steadmanhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxHonestly, having worked with startups, and for software vendors, there isn't a lot of IP that's worth protecting. Most of it is common procedures that are rewritten. An accounting application having IP? Come on, those are set, published rules for handling finances. They're publicly published, otherwise you couldn't implement the system.If it is that critical and unique, you'll know if a competitor steals it and you can sue them.If clients cause support issues, that's good, right? You charge them more if they constantly call because of "tuning" and sooner or later the guy writing the check tells the guy touching the code to stop.Fri, 10 Apr 2009 08:32:42 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI guess I'm peculiar. To my mind stored procs are for *database* logic, not application logic. Therefore I can't see a need to encrypt your sprocs since that's just obfusticating (and not very well) the design of the data--which is already complicated enough thank you, even following KISS principles.In other words, to me sprocs are there to support integrity and not much more than that. I like having database logic in the database when the app doesn't need to mess with it, but it's all more or less mechanical logic. The real value of code lies on the application side, not the data side.(Can you tell I'm from an app development background :))Fri, 10 Apr 2009 08:26:05 GMTroger.plowmanhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI am against encrypting procedures. I understand people being concerned IP rights, but if you are that concerned, put that logic in the application, not the database. The only experience I had with a product that encrypted ALL the procs was negative, because it kept me from helping them debug the code. Yes, I decrypted one proc that was causing a problem, and I made a suggestion based on what I learned, without telling them I had seen the code. It would have been a lot easier for everyone if I could have said, "You have this problem on line X of proc A".Fri, 10 Apr 2009 08:16:17 GMTJack Corbetthttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]Steve Jones - Editor (4/10/2009)[/b][hr][quote][b]azz (4/10/2009)[/b][hr]Absolutely agree, that "If you can deliver a well performing, and good looking application, no one cares about the code." But are there a lot of such applications ordered by middle and small size companies?I think the absolute majority of applications are tested to "good-enough" state where developers assume maintenance issues.[/quote]You think so? I've worked in small and medium companies, and we've rarely been allowed to touch a 3rd party app. Even changing indexes for performance is frowned upon because of support.[/quote]I work for a software company. We deal with both Oracle and SQL Server databases (fun and games, I can tell you). One time we had a client pay a consultant to tune one of our queries. They did this with something called an Oracle overlay - I never did work out exactly how they did this - that basically waited for a query with a specific signature to be used by our application, then would automatically replace it with their own tuned query. I was amazed by how much money they spent. It had never occured to them to call us to tell us they were having a problem. When we did find out about it, we of course fixed it - as part of their support agreement. In other words, at no extra cost than what they were already paying.Fri, 10 Apr 2009 08:03:50 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]Steve Jones - Editor (4/10/2009)[/b][hr]You think so? I've worked in small and medium companies, and we've rarely been allowed to touch a 3rd party app. Even changing indexes for performance is frowned upon because of support.[/quote]Absolutely. It took an act of god, otherwise known as the Head Legal Counsel, and our corporate checkbook for our investment accounting vendor to allow us 1 minor change... To work-around a bug in the vendor's own code!Fri, 10 Apr 2009 07:57:23 GMTJason Miller-476791http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]azz (4/10/2009)[/b][hr]Absolutely agree, that "If you can deliver a well performing, and good looking application, no one cares about the code." But are there a lot of such applications ordered by middle and small size companies?I think the absolute majority of applications are tested to "good-enough" state where developers assume maintenance issues.[/quote]You think so? I've worked in small and medium companies, and we've rarely been allowed to touch a 3rd party app. Even changing indexes for performance is frowned upon because of support.Fri, 10 Apr 2009 07:47:00 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxI see that almost all responses are against encrypting. The few that have done so were to basically try to secure critical code for their system. My perspective is that even the critical code should not be encrypted. If something is critical to your system and the company running your application is having a problem AND has a knowledgeable person that could investigate but not change anything, they might be able to see what is tripping by looking at how the processes are designed. If it's encrypted then the company is dead in the water until they get support from the vendor who encrypted it. In today's age, this company might be out of business or the person took off that encrypted it.Folks, I've seen this with chemical instrument vendor in Milwaukee. They sold the business once, lost all of the developers, then someone bought this other company. So all of the knowledge of the design was gone. Your software may survive longer than the company you work for, or you built it for. The other reason some people encrypt is for more or less job security. I have two words for that - YOU'RE FIRED. The best way to have job security is to be knowledgeable, helpful, and share your experience to help others. Someone who has to squirrel away their knowledge is useless.Fri, 10 Apr 2009 07:43:51 GMTMichael Koberhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxWe provide a suite of functions replicating EXCEL functions for SQL Server using SQL CLR. Based on the traffic to our web site (www.westclintech.com) it is clear that there are a small number of people who download the software for the purposes of reverse engineering it. We are certainly not concerned about real users of the our software reverse engineering the code and violating the terms of the EULA, but not everyone is so inclined.Fri, 10 Apr 2009 07:43:28 GMTcharles.flock-906611http://www.sqlservercentral.com/Forums/Topic694571-263-1.aspx[quote][b]athurgar (4/10/2009)[/b][hr]Encryption besides being annoying and pointless, it can also be dangerous if you lose the source code (a malicious attack by a disgruntled employee about to leave). Also I always thought that there must be some performance overhead of encryption/decryption- even if ever so minor.[/quote]I had this happen, sort of, in my first Denver job. The previous DBA had encrypted all procs on the v6.5 server, which wasn't a big deal, except that he got fired. He, along with the asst DBA had been using SourceSafe, which was good, but they had it configured to leave copies of the procs on their machines even though they'd checked things into VSS. What's worse?They also had multiple copes of many procs on their machines in different folders. So we had no idea which was the "current version" on the servers. I ended up decrypting hundreds of procs, which was a time consuming weekend project, and reloading VSS.Fri, 10 Apr 2009 07:36:29 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxOver the years I have evaluated many software systems for purchase and I have yet to recommend one that used encrypted procs. I assume that if they encrypt their procs they are somewhat ignorant of how things really work or are just trying to hide something. With only one exception, we have opted not to purchase applications that use encryption on their procs, and that was because it was a highly specialized application that really had no competition in that particular space. I have not yet seen a product that we considered "best of breed" to employ this tactic...ever!The license agreements all state that we cannot make changes to the application, but being able to look at the procs does make it quite a bit easier to troubleshoot and solve performance issues.Fri, 10 Apr 2009 07:34:07 GMTDCPetersonhttp://www.sqlservercentral.com/Forums/Topic694571-263-1.aspxNo, never had the need or felt the need to encrypt stored procs. Could be a good thing though, from stopping people from stealing your code. What I am about to say might just freak some of you out. Whenever one of my clients needs a script I write it (got a copy of their database) and e-mail it to them. Then they phone me and I help them copy it into their database. I also help them, telephonically, to create/change a query for stats etc. that they want if it's not too difficult. So, if I encrypted the stored procedures that wouldn't be possible.Happy Good Friday to all!Fri, 10 Apr 2009 07:22:06 GMTManie Verster