Scenarios and Goals of the Security Application Block
- Obtaining a temporary token for an authenticated user
- Authenticating a user using a token
- Ending a user session (expire a token)
- Determining if a user is authorized to perform a task
- Authorization
- Security-related caching and session management
 Note: |
|---|
| If you use the Security Application Block to cache security-related information, the default caching store provider for the security cache is the Caching Application Block. Although the Caching Application Block can be configured to encrypt cache data in backing stores, the application block does not support encryption of cache data stored in memory. If an attacker compromises the computer and accesses the memory of your process, he or she can access information stored in the cache. If this threat is significant for your application, you should avoid storing sensitive information such as credit card numbers or passwords in the cache or use an alternate caching store provider that supports in-memory encryption. |
Code Protection Best Practices, Part 2
Debugging Protected Assemblies
The Secure Virtual Machine (SVM) protection process does not provide reversing tools, however, you can use the following guidelines to simplify the analysis of unexpected errors that occur within protected methods.
- Do not use method cloaking. Method cloaking can obscure the call stack at the error point. This is good to impede hacking, but makes life very difficult when analyzing the source of an error. This feature is turned off by default.
- When throwing exceptions or logging errors (during development of the unprotected code) insert a unique error identifier for each location in the code (e.g. a GUID). This will leave the code obscure, but will allow the developer to pinpoint the line that generated the error based solely on this identifier.
Unsupported Method Constructs
SLP Code Protector does not support the transformation methods with the following constructs.
- Methods within generic classes.
- Methods containing explicit instantiation of generic types.
- Methods with generic parameters.
- Non-static methods of a structure.
- Methods with out or ref parameters.
- Methods that invoke other methods with out or ref parameters.
- Methods that modify any method parameter, even if the parameter is defined as a by value parameter.
- Methods with a variable number of parameters (for example, the params keyword in C#).
- Methods with too many local variables or parameters (> 254).
- Methods that contain calls to Reflection.Assembly.GetExecutingAssembly method, Reflection.MethodInfo.GetCurrentMethod method, or Reflection.Assembly.GetCallingAssembly method.
- For the Microsoft Common Language Runtime (CLR) 1.1 only: methods that create objects by using constructors with a variable number of parameters. This restriction does not exist when a non-constructor method is invoked.
- Implicit and explicit cast operators cannot be transformed to the Secure Virtual Machine (SVM).
- Unsafe code – For example, in C#, methods that contain the keyword unsafe cannot usually be transformed.
If you attempt to perform an SVM transformation on a method that violates one of the unsupported constructs in this section, SLP Code Protector will issue a warning.
Posted in: .NET Framework| Tags: Code Protection Best Practice .NET Code Debugging Parameter identifier part protection method methods error refCode Protection Best Practices, part 1
Microsoft Software Licensing and Protection (SLP) Code Protector provides ability to specify exactly what code to transform. This permits the developer to accomplish two things: balance the security of protected code against the performance of the application, and to reduce overhead in ways that no other code protection mechanism allows.
Protecting Critical Intellectual Property
When selecting code to protect, choose those classes and methods that have a high intellectual property component, or that are particularly vulnerable to hacking or reverse-engineering. These include the following:
- Staging or initialization methods that permit access to functionality you want to control.
- Methods that enforce licensing.
- Code that implements algorithms which are unique to the product.
- Code that contains information about the infrastructure of the enterprise: database connections, passwords, etc.
However, how you apply protection is as important as the content that needs the protection. As with any advanced technology, SLP Code Protector has advantages in performance depending on the level at which code protection is applied. In some cases, the level at which protection is applied can significantly lower the performance of an application.
Managing Performance
There are certain code protection scenarios where the performance of a protected application is slower than the unprotected versions. This is usually the result of applying protection to methods containing iterations of complex calculations. For example, executing a math operation on every pixel of a bitmap graphic as part of an image processing application would negatively affect performance.
To work around this limitation, we recommend applying protection to methods that are not computationally intensive. In cases where you want to control access to a computationally intensive method, you can protect “gateway” methods — that is you protect the non-computationally intensive methods that call the computationally intensive methods. Consider a scenario where you are applying protection to an image processing application. You have implemented an algorithm that sharpens the image to enhance the clarity of captured images. To access this feature, users click Sharpen from a menu. The method that performs the work contains the iterated complex math. However, if you apply protection to the menu item, Sharpen, you can control the use of the feature without having to protect the computationally intense sharpen method.
Posted in: Others .NET Framework| Tags: Code Protection Best Practice .NET