Naturally, this documentation and the samples that compliment it, is a good effort in showing you how to use Protection PLUS 5 SDK. However, there are other practices with which you need to concern yourself with in order to ensure your protected application operates both securely and efficiently.
If there is something you are not entirely certain about regarding your application's security or performance, ask questions! We have plenty of resources available online that supplement this manual and can provide you further guidance, and you can always get help from us if you have trouble finding information.
An entire manual could be dedicated to security practices; however, the focus of this section is to give you some high-level guidance meant to help you avoid some of the most common things that can lead to your application's licensing mechanisms being bypassed or compromised.
The Protection PLUS 5 SDK .NET libraries (such as PLUSManaged and PLUSManagedGui) are obfuscated, but this alone cannot prevent a hacker from modifying your application's source code. When your .NET application is compiled, it is compiled to what is called Microsoft Intermediate Language (MSIL - pronounced like "missile") code. There are tools that can be used to translate and reverse engineer MSIL code, so it is imperative that you select and use an obfuscation tool to further protect your application and your investments in it. Microsoft offers a good summary of this subject.
It is possible to obfuscate your application in a way which embeds the Protection PLUS 5 SDK libraries with your application. This is recommended where possible, as it works with PLUSManaged and PLUSManagedGui, provides some extra security with most obfuscation tools, and can help simplify your deployment (as won't be necessary to distribute the library once it is embedded in your application).
Using strong naming with your .NET assemblies or applications is an easy way to help prevent hackers from altering your application, and is often already required if your application is designed to integrate with other applications (such as SharePoint). Microsoft offers a good summary of the benefits using strong-named assemblies.
There are entire books and texts on the subject of cryptography, and even various facets thereof. However, this manual offers a good summary of how Protection PLUS 5 SDK uses cryptography. Make sure you understand this content and how it pertains to your licensing requirements.
Your application will use encryption key data specified in your SOLO Server account. Should a hacker fully compromise this key data, it could become possible for them to arbitrarily write or rewrite your license files, which could make it possible for hackers to completely bypass your licensing logic. Consequently, it is very important for you to protect this key data in your application:
Any point where your application is open to interaction from users is also open to interaction from malicious applications and scripts. Similarly, any data you receive from the system is data that could also be manipulated by a malicious script or program. Some simple things you can do to prevent these sorts of things from tricking your licensing include:
If your application has any critical features or functionality that are part of your core intellectual property, validate the license file in that area of code as appropriate. Make sure you only do this within reason, as you would not want this to have a negative impact on your application's performance. Furthermore, try to keep these extra checks limited to validation of your local license file, and avoid using background checking with SOLO Server over the Internet, which could result in your application appearing to be sluggish when Internet connectivity is not very fast or reliable.
Somewhat related to the point above, it is common to have visual elements (such as buttons or menus) that run important features or functionality, and it is also common to disable those elements when the application is not licensed to use this feature. Although this does prevent a user from clicking on the element with a mouse, it is possible for another application to be used to send a "window message" to that element to emulate a successful click even when the element is disabled! While disabling elements is a good visual indicator for your users, it is important for your application checks its license to ensure it really is allowed to use the given feature when your application handles a "click" just in case.
Data from the system can be altered in a number of ways, ranging from altering the system's data or configuration directly, to using function hooking to trick your application into calling a hacker's code instead of the operating system's code. Without going into too much depth on how these attacks work, a good way to explain this is to provide the example of evaluating a system's time. If the system's clock has not advanced since your license was last saved, since your application started, or since just about anything was done at any point in your application, then it is fairly safe to assume the system's clock is either actively altered, or the API's being called to acquire this information from the operating system have been hooked to trick your application. Although this kind of tampering is next to impossible to prevent, the good news is that it is very easy to detect and respond to it in your protected applications, and the Protection PLUS 5 SDK APIs offer ways to easily detect this sort of activity. Furthermore, if you limit the amount of time the application or any of its features may be accessed, make sure you test for this kind of tampering throughout various parts of the application, as this will make it more difficult for hackers to develop applications that time when it alters things to try to bypass this check in your application.
Performance is another one of those subjects for which there are many books available. This section is meant to provide you some guidance on avoiding common performance issues.
Reading and writing files can generally seem fast when you only do it once; however, if this is something that is done frequently, it can quickly add up and make your application feel sluggish, unresponsive, and clunky. Be careful about how many times your application reads and writes license files, especially since these files are heavily encrypted. Additionally, you should take particular care to consider caching license file data in memory for high-concurrency applications, such as Windows services or daemons, web applications, web services, etc...
This is somewhat related to avoiding too much file I/O. If your application reads and writes to the license file too frequently, it can drastically reduce performance. Furthermore, it is very important to make sure your application does not background check or refresh its license with SOLO Server too frequently, as this can also have a dramatic affect on your applications overall performance and could even affect the server's performance. While we would never want to understate the importance of security, it is just as important that users have a pleasant experience with your application.