Advice on Registration Approaches

[Richard Gaskin]

Igor de Oliveira Couto wrote:

> Is any of these methods more effective than another? Less costly?
> Better liked by the end users? Easier to manage? More suited to the
> Revolution development environment?

IMHO, there are two rules for protecting your app from piracy:

1. Everything is crackable.
2. Most crackerz are not customers.

When I first started seeing WebMerge serials all over the Web I got really
nervous.  So I blocked those codes, and when I made version 2 I built a very
different keygen algorithm that should be sufficiently annoying to dissuade
most.  Then I went back to work on features.

Nothing is ever truly secure on the 'Net, so the trick is not to seek the El
Dorado of "uncrackable", but instead to simply find the cost-effective
balance of security vs. usability and development costs.

Your own needs will vary depending on the market you're addressing and what
your tool does, but I can tell you what I did with WebMerge as one example:

As a tool that generates static Web pages from database output, WebMerge is
uniquely valuable (ironically enough) to pirates illegally publishing lists
of reg codes.  So, as with popular games, it will attract the attention of a
class of people who may be unusually adept at cracking and who generally do
not pay for software.  So efforts to stop them would become a case of
diminishing returns rather quickly.

I've been focusing instead on the potential paying customer.  I started by
asking asking myself this question: "What protections can I develop in
minimal time which will sufficiently dissuade the casual serialz user?"

But then I had a couple of purchases with stolen credit cards.  The
transactions are fully legit -- they _are_ paying, and the card account is
good.  It just doesn't belong to the person using it.  So they get a reg
code, and (as with Microsoft, Apple, Macromedia, Adobe, and most others) it
winds up on the 'Net within days.

There is nothing you can do to completely protect yourself from fraudulent
cc purchases.  And truth be told, Visa and MasterCard are only interested in
issuing the chargeback, and generally don't investigate loss transactions.
They will focus on protecting their customer, but once the chargebacks have
been issued they rarely lift a finger to protect the vendor.  In my case,
because I have the email headers and IP information for the person logging
making the purchase, chances are they could obtain the court orders
necessary to find out which computer the transaction was made from,
significantly narrowing the range of suspects, in some cases down to one.
My offers to submit my transaction records to their investigative teams have
not yet met with reply. It appears only the largest cases of identity theft
are investigated; the majority of small-time players remain in action.

So between crackerz (some of which you might be able to stop) and credit
card felons (which you cannot stop), whatcha gonna do?  For myself, I
changed my question, to: "How can I provide a compelling reasons for Web
professionals to give me money?"

This focus helps me keep my eye on the true ball, which is delivering a
worthy user experience to the target audience.  I figure some of the
WebMerge audience will be comprised of those who might be tempted to use a
stolen serial if they come across one, so instead I try to make it clear
that software clearly pays for itself, often in the first use.  Inspired by
Raney, I work hard to provide timely and complete support, even offering a
toll-free number for the first year (support is an important component with
a developer tool like WebMerge).  I keep the product reasonably priced,
provide quick turnaround on bug fixes, and add new features almost monthly.
Any professional with a need for the product will recognize that it's in
their interest to pay for it.  The others can't be bothered with, there's
nothing I can do for them.

Any system where the serial numbers can't be easily guessed seems sufficient
for the major publishers, so it's become sufficient for me.  And you can
build such things in Rev.

Your reg key algorithm may be one in which the key is derived at least in
part from the user name (Rev and MC use such a scheme).  Or you could have a
reg scheme in which each character of the key is derived from some arthmetic
on other characters in the key, which merely makes it difficult to
extrapolate other serialz if someone tries to use variants of one you
blocked.  Or some combination of the two.

You'll want to hard-wire a list of current blocked codes with each release,
and of course password protect all your stacks to encrypt your code and
comments.  

You could optionally have your software "phone home" as Ambrosia does, and
with a Rev-based CGI of the server side you could make a pretty nifty
system.  But be mindful of your audience: such a scheme may be problematic
if your user does not have always-on 'Net access.  When it phones home it
submits the user's reg info for your database, and checks the code against a
list of known stolen codes on your server.  This way you can block stolen
codes the moment you come across them by just adding them to a file on your
server.