I do something similar, however, I store the information for each activated wordstation in a table. I also have a ChkSum integer field in the table as well. I use SYS(2007) plus some arbitrary formula on EACH field in the table except the ChkSum field. I then store this total in the ChkSum field. If so much as 1 letter is changed in any field, the sum of the ChkSum values plus the algorithm will not match the value in the ChkSum field. I then know if someone hacked the table data. I then cancel the app login/launch process with a message to the user. Here is the code I use:

local lnChkSum, i, lcFName
lnChkSum = 0
if empty(dbf())
   return 0
endif
for i = 1 to fcount()
   lcFName = field(i)
   if lcFName = "CHKSUM"
      loop
   endif
   lcData = transform(eval(lcFName), "@T")
   lcVal = Sys[2007, lcData ]
   lnChkSum = lnChkSum + val(lcVal) + (i ** 2)
endfor
return lnChkSum

The + (i ** 2) is arbitrary and is undocumented so a user can't just use a checksum value. I use a different arbitrary formula which I also do not divulge.

>Hello,
>
>Recently I've been looking at different ways to create unique keys to stop users from using my companies software w/o payment.
>
>Currently we program the users specific information into the program. This works because our software sends out invoices, etc to the companies customers. So, say we sold our software to 'Blah-Blah Company, Inc.' and they tried to give it to 'Illegal Pirates, Inc'. Illegal Pirates would find that at the top of all invoices and reports the name 'Blah-Blah Company' would be show. Unless they had a LOT of white out they'd have to buy their own copy.
>
>Anyhow, this system works fine but this process is EXTREMELY laborsome when we update the program, which we are in the middle of doing. The idea of making 1000 different copies of the program w/ unique address information frightens me.
>
>So we're moving to a unique key system. And this is where my question comes in. Obviously we don't want to use a system like Windows 95 or 98 because a user could simply give his friend his key. So we've come up with a 'seed key' idea.
>
>The user installs the software, they are prompted for their address information. They type the info in and click on okay. At this point the software looks at the computer and grabs a couple unique ID's from the computer, say from a NIC and the HD. It then creates a hash (the seed) from the ID's and the address information. The customer at this point can call us and give us the seed or go online and type the seed in. On our end we type the seed in and get an activation key that we tell the client. They entire the activation key in and the program is ready to go.
>
>Now the activation key is based on the seed, so when it is entered the program compares the seed and activation code. This way each customer has a UNIQUE activation code and if they make copies we don't care because they'd have to have the activation code for that address AND that computer.
>
>Pitfalls of this system:
>- Users have to go through more work to get their program running.
>- Users would need multiple activation codes for a network setup.
>- Could possibly be decrypted if they new what we're looking at.
>- If a user upgrades they need a new activation code.
>
>So my question, are there more pitfalls I havn't seen? And what's a good way to make a hash in VFP?
>
>Thanks,
>Bryan Smith
>
>PS: Sorry so long.