Re: [OT] serial number validation algorithm?
Re: [OT] serial number validation algorithm?
- Subject: Re: [OT] serial number validation algorithm?
- From: mathew <email@hidden>
- Date: Mon, 6 Oct 2003 21:43:25 -0400
On Monday, Oct 6, 2003, at 07:15 US/Eastern, petite_abeille wrote:
Assuming I have the right ingredients to seed a SN, what would be the
most straightforward way to validate such a number?
It depends what you mean by "validate". There are two different kinds
of validation, and if you consider credit cards you can distinguish the
two:
Looking around the net, I stumbled upon what credit card issuers seem
to use: the "Luhn Formula".
Here is an illustration:
http://www.brainjar.com/js/validation/default2.asp
The "Luhn formula" is used to check that a number entered into a
computer system is syntactically valid and could potentially be a
credit card number. The idea is to detect common typos, such as
mistyped digits and transposed digits.
The second type of "validation" is checking whether the number actually
corresponds to a credit card account in good standing. I'm assuming
this is the thing you really want to do. Luhn won't be good enough for
that.
First off, let me say that I'm speaking as someone who's registered
over a dozen pieces of shareware, someone who has released shareware
and freeware, and someone who has written serial number code for
commercial software.
Now, for shareware serial numbers, I'd make a few suggestions:
1. Use a scheme similar to the Luhn algorithm to catch input errors.
Often
people end up copying serial numbers down onto paper, or re-entering
them from a paper copy of an e-mail.
2. Allow your registration dialog to accept pasted registration codes.
I'm
amazed by the number of people who seem to go to deliberate effort to
prevent me from copying and pasting my registration code, and force
me to
type it in again.
3. If you can reasonably demand that the user has an Internet
connection,
you may want to consider having the software verify the code by
connecting to a server. This will cut out casual piracy by "sharing"
registration codes.
As far as picking an algorithm for the software to check the code and
turn off the pre-registration restrictions, I'd suggest using a
well-known digital signature algorithm such as MD5. Suppose the user
sends you the name "John Smith"; you append a secret string to get
"John Smith MySecretString" and run the result through MD5 to get a
hash. Part of that hash is then the registration key. When the user
enters his name and the registration key, your software appends the
same embedded secret string to the name, MD5s the result, and checks
that the right part of the hash matches the registration key that was
entered.
Sure, you could do public-key crypto, but it's not worth it for a piece
of shareware. The user can potentially run the debugger on your code or
disassemble it, and simply patch out the registration code, so you only
have to come up with something that's harder to hack than that. MD5
will do. Hell, a simple CRC would probably do... For expensive
commercial software, more elaborate precautions might be necessary.
A couple of other things:
4. When presenting the registration code to the user, use a restricted
character set. The one I recommend is ACDEFGHJKLMNPQRTWXY34679
This is A-Z plus 0-9, with all the characters that might be confused
with each other removed. (e.g. 8 and B, U and V, 2 and Z) This
immediately drastically reduces the possibility of transcription
errors,
reducing user frustration and support costs. So, use the above as
your
character set and represent your binary hash in base-24.
5. Don't make the registration code too long. You only need to check
part
of the signature hash. 8 characters chosen from the 24 above gives
you
over 100 billion combinations; nobody's going to brute force that, so
anything more is being needlessly obstructive to the user. (Ever
entered
a Microsoft Windows registration key?)
Some other general suggestions:
Make the demo period generous.
Remember that the user may try the software once, forget it for six
months, then try it a second time.
Make the software do at least something useful without registration.
People are less likely to register software if they can't prove it
actually works first.
Keep your prices low. Conventional software distribution needs big
margins to pay for shelf space; you don't have those costs. If you
charge $10 or less, people may buy the software as an impulse buy. If
you charge $50, they're unlikely to.
Let people use the same registration code on a reasonable number of
machines, at least a desktop and a laptop system. Remember, you're
lucky they want to register at all, don't double the price just because
they sometimes sit in Starbucks with an iBook.
Always remember that your software *will* be pirated. The purpose of
registration codes is to keep honest people honest. Remember that when
writing the text messages too! Treat your customers as thieves and
they'll feel no loyalty to you.
And if you're planning to earn a living from writing shareware, check
out the ramen recipes at
<URL:
http://mattfischer.com/ramen/recipe.html>...
mathew
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.