More On Policing Shareware

RHW22 writes "Washington Post's Rob Pegoraro looks at shareware, focusing on the question of whether or not this industry can survive if people never actually cough up $$ for the product. He mentions Ambrosia Software, 'a developer of Macintosh games and utilities in Rochester, N.Y., could stop guessing after it revised its payment system last year. The new system aims to stop people from using pirated registration codes in two ways.' Read his column here." We mentioned this several weeks ago, with a link to Ambrosia's description of their system and what led to its adoption.

Comments

Then you never really own the software!

[zerofoo]

When I purchase software, I own the product. The problem with expiring registration codes is that you only own the software as long as the company is in business.

What happens when Ambrosia goes out of business and the software code expires? Your product that you PAID FOR stops working.

Can you imagine the impact of GM going out of business and then finding your car doesn't start the next morning? You paid for that car, and you expect it to function correctly for the expected life of that car.

Expiring codes, WPA, and all the other software piracy/protection schemes out there remove control of the software from the end user and shift it to the software vendor. It is only a small step to software as a subscription service after that.

I'm really glad my Linux machine is totally free and if Microsoft, or Ambrosia goes out of business it will still keep working.

-ted

Re:Then you never really own the software!

[MajroMax]

When I purchase software, I own the product. The problem with expiring registration codes is that you only own the software as long as the company is in business.

If done right, this isn't strictly true. A registration system only needs to rely on central servers if data used for the authentication process changes, such as a System ID or a timestamp, the latter being used in Ambrosia's system.

A simple authentication system would take the registree's name, address, and perhaps a keycode given at regtime to create a hash for the authentication server. If that hash is valid (meaning the registration actually happened), the authentication server will respond with a countercode that the program uses to unlock itself. If this countercode is not time-limited in any way, there's nothing logisticially preventing it from beging shown to the user, and thus permanently recorded; it will still be valid so long as the user remembers his name/address/etc.

If changing data is used for the hash, however, then there's a trickier situation if the authentication servers go permanently down. Most schemes would have the server respond with a sepereate countercode, and thus an old one would not work to unlock the program.

One solution to this problem is a master-key; a nonchanging constant that could be released if the company goes out of buisness. This creates security flaws, however, if the key is found out before the company goes out of buisness. Also, having a master key for the product out there would significantly reduce the possible value of the software "asset" in bankruptcy proceedings, so the courts might not allow the key to be made public.

A possibly better alternative would be to have the company release a patch that turned off the date-checking code in the program. Although this doesn't create any security holes in the product while the company's still alive, it does require that the company know it's irrevocably going bankrupt, and the programmers must have enough knowledge about the banakrputcy and power to release the patch -- neither of which are particularly likely in large corporations... after all, management can spin off the now-crippled masses as a "customer base" for future revisions to be sold at auction.

What's really needed is some sort of "dead-man's switch" so that if the company suddenly drops off of the face of the earth, the software will still work. To do this, the software should become non-functional if it receives a negative response from the auth server, instead of becoming non-functional if it fails to receive a positive response. The reg-server hostname should be hardcoded into the software somewhere (binary data file or program executable -- NOT a plaintext file), and the software (given use of an expired regcode) will try authenticating with the server on run and every hour or so until it receives a positive or negative response, in which case it will update its datafile and not try again (with that regcode).

"But Wait!" you say, "Isn't that system inherently insecure, as malpeople can crack the software or selectively block access to the auth servers?"

This is true, but, as the Ambrosia article says, the vast majority of people will do very little beyond trying a cracked regcode -- even installing a crack is beyond the vast majority of people who would typicially use the software; configuring special firewall rules is probably out of the question. (This is also why I said "put the server info in a binary file", as instructions to remove the data from a textfile is easy enough for most users.) Software registration is a game of 90%'s, so eliminating 90% of potential copyright infringers is about as good as you can get for reasonable effort. For people who _do_ tell Zonealarm to not allow the program to connect, a nag screen on startup to the effect of "This software has not verified its registration, click OK to continue" will get another fraction or two to register -- admittedly, it would be a pain if the company went out of buisness, but it doesn't have any bearing on the functionality of the software, especially for something noncritical like a game.

Running the software on a computer without internet access at all is another possibility of getting aroud the auth scheme, but that's becoming increasingly less likely as time goes on -- more and more computers are getting connected in some way, shape, or form, and shareware is largely distributed over the Internet now anyway.

Admittedly, this isn't a 100% perfect solution to the tradeoff between infringement-possibilities and functionality in the face of bankruptcy, but I'd guess that it's 80% of the way there, and it would require no changes to the keygen routines themselves.

--
The ideas expressed in this writeup are expressly placed into the public domain.

Is troll your middle name?

[WIAKywbfatw]

The way I see it, shareware authors shouldn't expect to turn a profit. They should just see being profitable as a nice perk.

Why shouldn't shareware authors expect to make a profit? Because you say so?

Shareware is a distribution model - you like it so you register it, recommend it to your friends, etc - nothing more, nothing less.

Too many people equate shareware with free, and those that resort to password cracks are the worst kind as they can't even use the "I just wanted to see if it was what I wanted" defence.

Sure, most people will take advantage of the situation and never register software that they decide to use beyond the trial period, but some people are more honest and will happily pony up $20 for a package that does the job they want done.

But saying that the authors, the people who invested their time and effort into code that other people benefit from, shouldn't expect to see a return on their work is downright unbelievable.

Re:Some helpful links with reg code generation inf

[jmaslak]

Okay, you want to write your own key generator.

My advice:

1) Use RECOGNIZED encryption & hashing algorithms. Do NOT invent your own!

2) Don't shorten the result from a hash. I recommend at least 128 bits of entropy in the key (if you use Base64 to represent your key, you need 22 characters)

3) Use public key encryption to prevent giving away your secrets.

An example protocol:

User sends his name (case sensitive) and the current timestamp (both of which the client stores to use in future validation) to the "authentication server" which also takes his credit card number. After receiving payment and validating the timestamp, it generates the registration code as follows:

1) Take the username, timestamp, and a secret symetric string (which will be embedded into the client, but, thus, vulnerable to attack). Concatenate them together with some sort of seperator (like a NUL character).

2) Take this new concatenated string and do some bit scrambling if needed. Take the MD5 hash of this new string and use for the next step.

3) Using RSA and a PRIVATE KEY (*NOT* embedded in your application!), encrypt this hash. Send the encrypted hash value in Base64 to the user. Remember he may need the timestamp as well to re-enter this value. The timestamp can be simply a day/month/year string.

To VALIDATE a registration string,

1) Decrypt the encrypted hash string using the PUBLIC KEY (embedded in your application). Because it is a public key, it doesn't matter if anyone knows it.

2) Verify that that hash equals the value of a hash constructed on a client using the user's name, his registration timestamp, and the shared secret embedded in the application.

Really, this isn't a secret science. But every game designer seems to think he is more creative then hundreds of experts on encryption. This is basically no different then a FFI (Friend or Foe Identification) system used on a military aircraft.

I *TRIED* to buy shareware.. this is the problem..

[takochan]

This is an interesting debate.

I think shareware authors should be paid for their work. Shareware is cheap, shareware is great..

But...

In fact, I tried on 3 instances to buy/register shareware.. and this is what happened.. I think this is part of the problem...

1)Trumpet (a TCP IP stack from several years ago).
Buy the program, registration never shows up in m ail.. wait.. email back and forth..wait some more.. in meantime, trial expires, re-install wait somemore. Client I am billing hours for is getting unhappy.. Calling to Australia to get it sorted out was not fun either.

2)DFX (an sound effects addin for winamp)
Liked it, and tried to buy a copy with their VISA card purchase screen... then.. nothing happens.. no registration comes.. nothing..wait days... nothing happens, no reply, no program... nothing.. I write email to them.. nothing happens..no reply..

Finally I *CALLED* the company, to ask them what is going on. They said that my visa transaction was rejected (but they never bothered to inform me of this, even though they collected my email address (just to send me spam I guess?). When I asked the sales rep at DFX what is wrong, they told me that my destination address and billing address were different, (I am an expat overseas) so.. transaction just gets automatically rejected, bin'ed.. period. No mail, no reply, no followup, nothing.. rejects just goes to /dev/null..

They didn't email me when the Visa was rejected (or ask where I live.. or anything), nor did they even bother to reply my original emails.
The answer the DFX rep gave me on the phone to all this was... "well, it is just a $15 program, so we can't spend too much effort (ie any!) to deal with things that might come up".

3)NJstar
It is a great program. But they wanted me to send checks to Australia or something in AUS dollars.. gee.. how to I do that.. the bank will charge me $50 in processing fees (after waiting in 3 lines at 20 minutes a pop because no one would know how to draw up a foreign denominated check), for a $25 program..

Those are my stories..

..and people wonder why they don't register their shareware...?!. ..

...because it is too complicated
to pay for it, thats why.. fix that, and then
I am ready to buy lots of great stuff.. but
right now it is just too much hassle I discovered,
so I just stay away from it..