Finding the Optimum Balance between Security and Convenience
Ensuring License Compliance
Independent software vendors (ISVs) want their customers to only have access to the licenses they buy. One of the ways that ISVs ensure that customers do not exceed their allotment of licenses is to place checks within their applications to limit how many licenses are used and where they can be used. Most ISVs use a license manager to perform these checks for both stand-alone and floating licenses. But ISVs are also careful to select a license model that minimizes inconvenience for themselves and their paying customers.
What is a Hostid and Why Do I Need One?
A software license manager uses the term hostid to refer to a unique identifier for a specific computer. The hostid is used by licensing software to lock a license (or pool of licenses, in the multi-user case) to a machine so that they can be used on only that computer. The hostid is a parameter used to generate the license key’s security signature, thereby rendering the license unusable if it is moved or its hostid is modified.
The Security v. Convenience Continuum
The decision on which hostid to use is usually based on trade-offs made along the security vs. convenience continuum. While this may not be immediately obvious, there are always trade-offs between making something (software, a car, a building) more secure vs. less convenient to access. Should it be accessed through a turnstile or a vault? ISVs should choose security-convenience policies that are in line with their beliefs and business models. Luckily, computers have many different elements that can be used as a hostid, so there is probably a hostid to match virtually any ISV’s policy goals. However, no single hostid type will satisfy every ISV, so let’s consider your hostid choices and examine the potential pros and cons of each one.
Three Important Issues to Consider:
As much as possible, you want the hostid to be native to the machine. In other words, you want it to be ubiquitous and its contents to be easily obtained via a standard system command. In this way, you avoid the delays, expense, and potential confusion of having to send special software or extra hardware to the customer prior to the sale of your products – everything is already there. Your customer can get your software up and running as quickly as possible.
… v. Security
For maximum security, you want the hostid to be difficult to modify, or at least non-trivial to modify. Most ISVs who use software license managers want to use the most secure hostid possible, but with an eye toward convenience (i.e. customer satisfaction) and cost control, at the same time.
Once Upon a Time…
From a software licensing point of view, an ideal hostid choice would be a standard unique serial number burned into every CPU. Intel tried this in the late 1990s, but the idea failed, not on technical grounds, but primarily on the basis of concerns over privacy. The fear was that software could be used to track users’ behavior and identity to a specific computer as they surfed the web.
The most common hostid choice is the Network Interface Card (NIC) Ethernet media access control layer (MAC) address. It is built into every modern workstation and server and can be easily queried through software. Although on some systems the NIC address can be re-programmed, creating the potential for the same license to work on multiple machines, connecting these machines on the same local area network will cause networking problems. So, although there are some security issues with NICs, they remain a good hostid choice.
IP addresses, or IP address ranges, are of little use as hostids from the software vendor’s perspective. Most users do not have fixed IP addresses, so they tend to be too transitory to rely on as hostids. However, IP address ranges are convenient for end users to use to allocate pools of licenses to specific sub-nets.
Disk Volume Serial Numbers
Like the NIC above, disk volume serial numbers are commonly used as hostids (Windows only). They are convenient, but do suffer from being easily modifiable, making them less than ideal from a security point of view.
Names as Hostids
What if you weren’t so concerned about security? What if you wanted your licenses to be valid no matter where your user installed the software? This is a pretty common vendor policy. In this case, it might make sense to use the customer’s username as the hostid. It’s also possible to use the hostname of the system as the hostid, giving the customer the flexibility to move the software to new hardware without getting a new license – as long as he resets the new machine’s hostname to match.
There are cases where you want to allow a license to run on any machine in a list. For instance, if a workstation has multiple NIC addresses, you could license to them all, and as long as one of them was found in the list, the license would be valid.
The Irrepressible Dongle
Dongles, small serialized USB devices, remain a good hostid choice for high-value software where security is paramount. Dongles allow your users to move the software from machine to machine by simply moving the dongle. The downside to dongles, however is that they add cost, must be shipped, can fail in the field, and they can be lost or stolen.
Hardware Serial Numbers
If you sell software on a specialized hardware device that has its own unique serial number, then the obvious choice is to use that number as your hostid. For you, this situation is probably ideal because the serial number is always there, and it is secure. Be sure to verify that the licensing technology you use can support a unique or non-standard hostid mechanism. Some licensing vendors provide ISV-specific callback routines to support just this situation.
If your goal is to simply tag your licenses, then you can serialize them so that you can identify the customer to whom they were originally sold. This is useful as a marker to track the original customer without tying the license to a physical host.
Custom Composite Hostids
By combining multiple machine identifiers, you can build a composite hostid where ALL of the identifiers need to match in order for the licenses to remain valid. This is a very strict approach leading potentially to numerous re-licensing operations whenever a relevant machine element is changed.