Re: [OT] serial number validation algorithm?
Re: [OT] serial number validation algorithm?
- Subject: Re: [OT] serial number validation algorithm?
- From: petite_abeille <email@hidden>
- Date: Tue, 7 Oct 2003 11:19:42 +0200
Hello,
On Tuesday, Oct 7, 2003, mathew wrote:
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.
Yep. This is exactly what I was after.
The second type of "validation" is checking whether the number actually
corresponds to a credit card account in good standing.
Yep. This is a separated problem. The Luhn formula (or such) is simply
to check the "correctness" of the SN. Not its validity.
I'm assuming
this is the thing you really want to do.
At the end of the day, yes.
Luhn won't be good enough for
that.
Yes. I understand that. In this case, this is simply to have a built in
"check sum" in the SN.
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.
Yep. This was the purpose of my original question.
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.
Yep. Very good suggestion. The easier the better :)
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.
Yes... unfortunately... in this specific case... this is not practical
for a bunch of different reasons... but... because of the nature of the
application (P2P), the SN is enforced at two levels: the application
itself and the local network.
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.
Yep. I'm using a standard digest algorithm.
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.
Yep. In a nutshell, this is exactly what I'm doing.
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...
Agree. The SN "enforcement" is not meant to be absolutely "fool
proof"... but rather "good enough" to prevent "casual abuses". If
somebody is motivated enough to fully disassemble an application...
well... more power to them...
For expensive
commercial software, more elaborate precautions might be necessary.
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.
Good point. I'm limiting myself to this character subset mostly.
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?)
Yes, this is a good suggestion.
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.
Yes. In fact, in this specific case, the app is fully functional even
without a license. Only its networking behavior is impacted by the
license.
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.
Right... I guess this mostly depend on which type of application you
are providing... in my case, this is not an "impulse buy" to start
with...
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.
Good point. In this case, the SN is tied to an email address. Not a
machine. You can use it anywhere you please, as long as there is no
clash on your local network.
Always remember that your software *will* be pirated.
Yes, you are absolutely right. I'm not going to waste time fighting
this loosing battle.
The purpose of
registration codes is to keep honest people honest.
Agree. This is not about stopping piracy from happening outright. If
somebody is motivated enough, they will find a way no matter what. As
you mention, this is more 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.
Good point :)
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>...
Hmmm... does cooking ramen helps?
In any case, thank you very much for taking the time to share your
experience :)
Cheers,
PA.
_______________________________________________
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.