Chapter 8: Security and Expiration
Security and Expiration
Setup Factory comes with installation security options that add another valuable layer of security to your application without sacrificing ease of use. Setup Factory's easy-to-implement security features make unauthorized use prohibitive without creating complications for authorized users.
This chapter will introduce you to the security options available in Setup Factory and get you one step closer to a secure yet easy-to-use installation.
In this chapter, you'll learn about:
• Security in Setup Factory
• Serial numbers
• Serial number lists
• The Verify Serial Number screen
• Serial number actions
• Date expiration
• Usage count expiration
• Log files, data integrity, and file encryption
• Internet authentication, post-installation security, and other important considerations
With the ever-increasing threat of software piracy, many developers are choosing to secure not only their software product, but also their installation. This extra layer of security prevents unauthorized users from installing the software and can assist in controlling the distribution of the installer.
In Setup Factory, there are two main ways to secure your installation. The first method involves utilizing product-specific serial numbers. From within Setup Factory, you can create and manage serial number lists. The serial number lists are encrypted once your setup is built. During your installation, you can prompt the user for a serial number using a Verify Serial Number screen or by creating your own custom screen. If the provided serial number is not found on any of your serial number lists, the installation will not continue.
The second method for securing your installation is to set expiration criteria. Your installation can be made to expire (cease to run) under certain situations. For example, your installation could expire after it has been run twice. Or instead, your installation could be made valid for a period of thirty days after which time your customer must procure the most recent version of your software. If the installation has expired, the user is alerted and the installation exits. The alert is fully customizable.
Think of a serial number as a pass phrase used by your customers to access the contents of the installation. Each user has a unique pass phrase. During the installation process, the user is prompted for this pass phrase to continue. The serial number provided by the user is then compared to the serial numbers in your list(s). If the serial matches, the installation continues. If the serial does not match, the installation exits.
In Setup Factory, serial numbers in your installation are grouped into 'lists.' A serial number list is an inventory of every valid serial number in your installation.
Setup Factory allows the creation of multiple (separate) serial number lists. One use of multiple lists would be if you wanted to distribute only one setup containing both a standard and enhanced version of your software. In this case, you would create two separate serial number lists, and based on the serial number that your customer provides to the installation, either the standard or enhanced version of your software would be installed. This method of separation is also valid for distributing both a demo and full version of your software in one installation.
In Setup Factory, your actual serial number lists are not stored in the installation. Rather, an MD5 hash (or "digest") is calculated for each serial number within each of your lists. These MD5 hashes are then stored in the installer instead of the original values. This ensures that your list of serial numbers is not vulnerable.
When the user enters a serial number, the installer calculates the MD5 hash for that value and then compares it to the list of MD5 hashes that were created from the original serial numbers. If a matching MD5 hash is found, the installer knows that the user's serial number is valid. (Since every MD5 hash is unique, the only way that the MD5 hashes for two serial numbers can match is if the serial numbers are the same.)
This allows the installer to detect a valid serial number without actually knowing what the original serial number was. Since the MD5 hash calculation is irreversible, there is no way for a hacker to retrieve the original serial numbers from the installer. The hacker is reduced to using brute force tactics, i.e. trying a series of serial numbers at random until one works…which, if your serial numbers are sufficiently complex, would be highly prohibitive.
Build configurations are collections of settings that you can switch between when you build the project. They essentially allow you to have different configurations of your software within a single project.
Every serial number list in a Setup Factory project can be associated with one or more build configurations. In other words, you can specify which build configurations a specific serial number list will be included in. This allows you to generate multiple editions of your product from a single project while still allowing you to include different lists of serial numbers in each edition.
For example, let's say you have two build configurations in your project: one for a Professional version, and one for a Standard version of your software. You also have two serial number lists, one for your Professional version, and one for your Standard version. By assigning each serial number list to the appropriate build configuration, you can ensure that each edition has the correct list of serial numbers in it without having to create and maintain two separate projects. You only have to worry about one Setup Factory project file; yet, as you build each separate configuration into its own separate installer, only the corresponding serial number list will be included.
Tip: More information on build configurations can be found in Chapter 11.
Once the decision has been made to use serial numbers to secure your installation, a list of serial numbers must be generated. Setup Factory has a built-in tool to generate lists of serial numbers using criteria provided by you.
Serial numbers generated with this tool are created using a serial number "mask" to specify the pattern for all of the serial numbers. In the mask, placeholder characters are used to describe the structure and format of the desired serial numbers. The built-in tool then replaces these placeholder characters with static and random letters or numbers automatically.
This tool is a huge timesaving feature. In mere seconds, you can generate a list of thousands of serial numbers formatted to your specifications.
There are two types of serial number lists that can be generated: random, and sequential. Generally, it is good practice to generate random serial number lists, unless you have a legitimate reason to generate a sequential list.
When considering what format your serial numbers should take, there are a couple of things to keep in mind. First, if you deal with more than one product, you may want to design serial numbers that are product specific (e.g. #####-#####-PRO-##### and #####-#####-STD-#####). Otherwise, if your two separate products generate enough serials, the chance exists that the same number may be generated for both products. As well, differentiating serial numbers according to product type ensures that human beings can differentiate between the numbers.
The second thing to consider is the length of the serial numbers. There is a delicate balance between the security of a serial number and the ease of entering it. A user will not want to enter a hundred-character alphanumeric string. Also, with increased length comes the increased chance the user will mess up a character in the serial number and call your support number unnecessarily.
If you already have a list of serial numbers that you wish to use with your installer, you can easily import them into Setup Factory. This is accomplished by choosing Commands > Import on the Serial Number List Properties dialog. Setup Factory can import serial numbers from a text file with one serial number per line.
Alternatively, if your serial numbers are in a spreadsheet program such as Microsoft Excel, it is possible to copy and paste the serials directly into the list.
Once you have serial number lists created, there are many things you can do with them. For example, you could import the lists into a label-printing program to create serial number labels to ship with your product. Or, you could import them into a database to keep track of your customers.
To import your serial number lists into an external program, you first have to export them from Setup Factory. This is accomplished by choosing Commands > Export from the Serial Number List Properties dialog. Setup Factory exports the serial numbers into a text file, with one serial number per line.
As another option, you can copy and paste the serial numbers right from the Serial Number List properties dialog into a spreadsheet program such as Microsoft Excel. exporting serial numbers
There are two steps required when adding serial number verification to your installation. The first is to create the serial number lists to be included with your installer. The second step is to prompt the user for a serial number during the installation process. This is done by using a Verify Serial Number screen. The Verify Serial Number screen is a ready-made screen template that is included with Setup Factory. It can be added into your project by clicking the Add button on the Before Installing screens dialog.
The Verify Serial Number screen is a modified Edit Field screen with pre-made actions on its On Next event. Right out of the box, this screen will take any serial number provided by the user and compare it to every list in the installation. If you want, the actions can be easily customized to compare the provided serial number to only specific lists in your installation.
Note: You can create your own Verify Serial Number screen; using the ready-to-use solution included with Setup Factory is only one option.
When a new screen is inserted into your installation project, it is inserted at the end of the list of screens. In Setup Factory, the order in which screens appear in the screen list is the order that screens will be displayed in your installation. Since we are treating a serial number screen as a 'locked door' to pass through before the installation can continue, it is good practice to place the serial number screen before any screens that you want only authorized users to see. A typical screen order would be: Welcome screen, License Agreement screen, Verify Serial Number screen, etc.
The same actions that are used by the Verify Serial Number screen to validate the user's serial number can be used to perform the same task elsewhere. You don't even need to use a screen for this purpose; for example, you could use a Dialog.Input action to ask the user for their serial number in a popup dialog box. Or if the user's serial number is stored in a registry key, you could retrieve that value using Registry actions and then use a SetupData.IsValidSerialNumber action to determine whether the serial number is valid for the add-on you’re installing.
The SetupData.IsValidSerialNumber action is incredibly easy to use…you just give it the name of the serial number list you want to search in, and the serial number you want to search for, and it returns 'true' or 'false' according to whether the serial number is valid.
Here's an example that demonstrates how easy it is to validate a serial number:
bValid = SetupData.IsValidSerialNumber("Main",
strSerial);
if not bValid then
Dialog.Message("Sorry!", Invalid serial number.");
Application.Exit();
end
In this example, we validate the serial number that was previously stored in a variable named strSerial against a serial number list named "Main." If the serial number is invalid, we display a quick message to the user and then exit the installer.
One of the expiration criteria available in Setup Factory is date expiration. When this security measure is implemented, your installer functions normally until the expiration date is reached, at which point it will cease to function. If the user runs the installer after the expiration date, they are presented with an error dialog, and the installer exits. (The message presented to the user can be customized.)
Note: Date expiration applies to the installer only and not to the software itself once it has been installed.
As you can see in the image on the next page, there are quite a few options for date expiration. Your installer can be made to expire at a specific date, such as the first of the month, or at the end of the current quarter. Or, it can be set to expire at a relative date, i.e., x days after the installer is built, or x days after the installation is first performed. As well, you have the option of displaying the number of days left to the user, or simply having the installer exit with no prior notice.
Note: The absolute date option, as well as the 'expire x days after build' option, can be used to protect the installer on more than one system. The 'expire x days after first run' option, however, is system specific. If the user runs the installer on one system, and then 50 days later runs it on another system, the installer will still function normally, even if it was set to expire 10 days after first run.
The second expiration option available to you is usage count expiration. Your installer can be set to expire after x number of uses either on a per-user basis (NT systems only) or on a system-wide basis. This is useful when you want your users to have the most current version of your installer whenever they run the setup, or when you want to allow only one installation on a system, regardless of the number of users.
Note: Usage count expiration can be used by itself, or in combination with date expiration.
Here are some typical usage count expiration settings:
You have the option of limiting the number of uses either by user or by system. As well, you can have the installation abort if the user does not have permission to write to the registry, since the usage information is stored there. Lastly, you can either display the number of uses left to the user, or have the installation expire with no prior warning.
Note: Usage count expiration is system specific. If a user runs an installer that is set to expire after one use, and then copies this installer to another system and runs it there, the installer will function normally on that other system.
In other words, this form of security does not expire the actual installation file; rather, it expires the installation on the current system by writing a value to the Registry. This process does not modify the setup file at all—the setup file will be the same after 100 uses as it was when it was first run.
Setup Factory's built-in logging function can quickly become a developer's best friend. It is enabled by default, and contains all the information that you as a developer will need to diagnose a setup gone bad, should that situation arise. Everything that happens during the setup is logged, from which screens were displayed, to what files were installed and where.
Beyond its basic components, the installation log file is fully customizable. You as the developer can choose what information is logged, and what information is not. If you require even more detail than what the built-in logging capabilities provide, you can add custom lines to the log at any point during your installation.
Using log files is invaluable to developers for diagnosing problems. And let's face it, no matter how much testing is done, there will always be one end user who hits a snag. Utilizing log files, you can find out exactly where that snag occurred, and fix the problem. As a result, you save on support costs and keep your customer happy.
Since all this information is (or can be) written to the log file, you may be wondering if log files pose a security risk. In general, no sensitive information is written to the log files by default. Unless you specifically write such information out using actions, the log files should be pretty safe. (Naturally the definition of what could be considered sensitive information may vary from one developer to the next. The best course of action, of course, is to test your installer with log files enabled, and see what kinds of information gets logged—both when the setup completes successfully, and when it encounters errors. If any information that you consider to be sensitive is revealed in the logs, you can adjust the default logging behavior, or turn the logging feature off.) Overall, since so little sensitive information is written to the log files, the risk is typically very low.
Furthermore, nothing is stored in the log file that the user couldn't access using third party setup-monitoring software. In most cases, the usefulness of the log file far outweighs any perceived 'security dangers' that may exist. The log file contains information vital to the diagnosing of installation issues, and by default does not contain any information that is not available to a user by other means, should they desire it. Since you can specify where the log file is created, and can control what information is included in it, there is no reason not to use the logging feature.
Ultimately, the choice of whether or not to use the log file, and how much information should be in that log file, is up to you.
Whenever using a process that deals with files, whether compression or simply copying, it is important to verify the integrity of the source files. After all, the quality of a copy depends on the quality of the original, and if the original file is 'broken,' it is not possible for the copied file to work.
Setup Factory handles file integrity verification by using CRC32 checksums. At runtime, the setup checks each file as it is installed onto the user's system. If it fails the CRC32 check, an error message is displayed to the user.
Note: CRC values are calculated using an algorithm known as the Cyclic Redundancy Check, or "CRC" for short. Basically, this involves generating a 32-bit number (or "CRC value") from the contents of a file. If the contents of a file change, its CRC value changes as well. This allows the CRC number to be used as a "checksum" in order to identify whether or not the file has changed. It also allows you to distinguish between different versions of a file by comparing its CRC value to the CRC values of the originals.
By default, the files that get stored in Setup Factory's data archive are compressed using a proprietary compression method. Although the proprietary nature of the compression scheme offers some security (e.g. a user can't just extract the files using a third-party tool like WinZip), it is not intended as a security measure.
If you need to fully encrypt any files, you can add Blowfish encryption to your projects using the Crypto actions in Setup Factory.
Note that it is equally (if not more) important to secure your software than it is to secure the installer. If you only secure the installation, all it takes is one user to install the files "legitimately" for the protection to be removed, leaving the door wide open for that user to share the files against your wishes—or for an intruder to steal those files from the user’s unsecured system.
When planning your deployment, it is wise to view the installer as an open vehicle for the files, and to focus on protecting the software after it's installed.
A very advanced method of securing an installer is to query a web database using HTTP.Submit actions. For instance, you could use a server-side script (e.g. a PHP script at your web site) to validate the user's serial number by checking it against the list of serial numbers that have already been used. If everything checked out okay, the server-side script would send back a special "key" to unlock the rest of the installation. If the server-side script rejected the user's serial number, the installer would abort the installation.
Note: Traditionally, software installers don't use such elaborate protection methods; usually when such authentication is in place it is implemented in the software itself, in order to continue protecting the software from being shared after the installation. However, this feature of Setup Factory can be used to securely distribute non-executable files, where the distribution itself is the only part that you can secure.
Tip: Setup Factory even has full support for HTTPS transactions. Simply use the HTTP.SubmitSecure and HTTP.DownloadSecure actions which communicate with the server using Secure Sockets Layer (SSL) instead of regular unencrypted HTTP.
Once your software is installed, any security measures taken to protect the setup do not protect the installed software product. Once your software is installed, Setup Factory's job is done. To ensure the security of your software product after installation, you may want to consider a third party security solution. There are many solutions on the market designed to protect your software product beyond the installation stage.
When planning out product security, it is important to keep in mind that given enough time and resources, even the best security measures can be circumvented. This fact can be illustrated with real-world, billion-dollar security attempts, such as DVD encryption and secure government communications. Given enough time, even these security measures can be 'cracked.'
In addition to securing your installation, and perhaps securing your installed application, you may want to consider controlling the distribution of your installation files. After all, a software thief can't steal something he or she can't find.
Serial numbers can be shared, computer clocks can be set back, and encryption can be broken. The advantage of imposing installation security checks is to make the task of stealing your software more difficult. Making a setup expire, by whatever criteria you choose, is a way to help control your source files. Using serial numbers is a way to track your users, and can be used for such purposes as limiting product support to registered users only.
One final point to keep in mind is that too much security can be a bad thing. While it is important to secure your application to prevent against unauthorized use, it is equally important to allow legitimate users a painless install.