Making a serial key for my software

[EVS]

Hi!

I have this program created and I have always been thinking about serial keys. How they work and stuff.

How about this idea - if one would employ a subscription-style payment system for his application in which customers would pay on a half-year or something like that basis in order to renew their subscription (antivirus and so on), how safe would this be:

1. supply a file (txt or whatever else), which contains a very (can be argued about - enough to cause confusion in a user with little IT experience) long sequence of numbers
2. the customer, after the payment order has been completed, receives this file and imports it into the system (this can be automatic or whatever, usability's not the issue here at the moment)
3. [within the system] the system takes certain digits out of the file, which make up the date until which the renewed subscription is valid and notes it somewhere internally.
4. now, until the expiry date, the system is working correctly.

Please, be honest and constructive critisism only!

Thanks!

[dglienna]

Numbers would have to be unique, and then, someone could copy the text file to someone else, then your key to unlock, and share that as well.

Look into Click-Once Deployment. It can expire in 6 months, or each use.

[EVS]

Well, as far as random numbers go, all the trash numbers could be generated by something like random(random(NUMBER)) and the places from which the 8 date numbers are taken would be unique for each customer (the customer-base wouldn't be more than 20 or so).

[ultddave]

If I understand you, this it what you mean:

Key1 1234567891
Key2 2345678910

Person 1 uses key1 and the program takes the digits 1 3 and 9
Person 2 uses key2 and the program takes the digits 7 8 and 9

So then the program uses 2 different read methods depending on the person who uses it. Which means each person needs a different "key interpreter" in his program.

Keep some things in mind aswell:
- What if Persoon 2 reads the key of person 1 ? So that will give 6 7 and 8, maybe that corresponds with a date too?
- If the key repressents the "ending day" of the program (sorry my english is pretty bad). Then you need to update your keys allot. Because if key1 represents " 29 August 2009" (2 month duration). But if you buy the program at "28 August" the duration should be set untill "28 October 2009" instead of "29 August 2009" (the day after buying the program).
So you need to update the keys .

That's why internet registration is pretty useful .

For example:
Person 1 enters his key1. The program connects to the internet (internet = required ofcourse ) and checks a database for, if the key is already used. If not => Person 1 may use his key. And the database checks key1 as "Used".

So when person2 tries key1 aswell, it will see that the key is already "used" and stops the activation.

That's what I would do later if I had a program .
Internet connection requirement = negative aspect , but it's the best way I can think of at the moment.

But if it's only for aprox 20 people. It might be too much work to make such a system . (However - If you should make it now, you know how to make it for future projects).

Hope this was of any help.

Greetz,
Dave

[EVS]

Thanks for that huge reply! Will give me something to think about!

What I had in mind was, that the *customer* after a certain period needs to re-receive his key in order to continue using the application; the key would look like a importable .key or something file containing this:
213109231209321983192392139210392109821093913891230981
123123123243434232131231098217392139072193974012983091
210983809210983092139128318230981098230912839210310989
...(a few dozen or hundred lines like that)
213123213213213124124214321321321123211323213122132332

the application upon import would know which 8 numbers to pick out of the bunch and they would make up the deadline (a.k.a. date) for the next need to import a new key again.

[ultddave]

WARNING: Long post detected .

If you are thinking about the internet registration thing I posted.
There is another downside. => What if a person formats his computer and reïnstalls his operating system. Then the activation key would be "checked as used" when he installs the program again (from the last registration), which is not good. Untill now, I didn't really find a good solution to prevent something like that.

Anyway;

Even if the key is 100 lines in length. Somebody will eventually find the algorythm (if it's spelled right) you are using to read the "date" from the key. If someone does, he can just make his own keys which last untill "2099" for example. And distribute those keys on the internet.

You could use a hash.

You can add a textfile with your document. With the following text:

FA0F1D1745F2DAE24345DF4556...

Which is the hash of the word "thisprogramownedyoubigtime".

Hashes are irreversible. Which means; If you give someone the hash FA0F1D1745F2DAE24345DF4556... he can't decrypt it back to a string. That's the power of a hash. There is no decrypting algorythm for it.

For example: http://en.wikipedia.org/wiki/Sha1

SHA1("The quick brown fox jumps over the lazy dog")
= 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

Even a small change in the message will, with overwhelming probability, result in a completely different hash due to the avalanche effect. For example, changing dog to cog produces a hash with different values for 81 of the 160 bits:

SHA1("The quick brown fox jumps over the lazy cog")
= de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3

This is an example of a very simple hash:

"input" AND 0
Hash Result: 0

As you probably know: 1 AND 1 = 1 ,,,, 0 AND 1 = 1 AND 0 = 0 AND 0 = 0

So as the result is "0", "input" can be either "0" or "1". So nobody will ever know if the real input was 0 or 1. You will never know - nor can you write an algorythm to find out. Because that algorythm has to make a guess.

A real hash is a little more complicated then that stupid example I gave.

------------------
------------------

But... this kinda has little to do with the "deadline" system you are using. I think you beter stick to your first idea for now . It's the easiest way as far as I know. =)

Greetz,
Dave

[dglienna]

They use to require a key device back in the early 90's to access the mainframe offsite. Users carried a sequencer that was the size of a pager.

It changed the key every 10 seconds or so. User had to type username, password, and the key (within 10 seconds). Our department had 50 of them, and they were NOT cheap.

[alrik]

Why dont you try this? www.keyzam.com

[MrViggy]

They use to require a key device back in the early 90's to access the mainframe offsite. Users carried a sequencer that was the size of a pager.

It changed the key every 10 seconds or so. User had to type username, password, and the key (within 10 seconds). Our department had 50 of them, and they were NOT cheap.

They still have sequencers, however they are keychain sized now, and the 6 digit number changes every 60 seconds:

http://www.rsa.com/node.aspx?id=1156



Viggy