ok, I read the presentation. Here are some important notes:
One issue is with communication to the server. How does the server know it’s talking to your plugin and not a key generator? Here’s the situation: the code that validates a serial key is sitting on the pirate’s computer. Once you have the code that checks keys it’s simple to randomly generate a set of valid keys and DoS the server looking for valid/non-blacklisted keys. I mean it would be suspicious if you get 1000 different key requests with the same MAC address, but if you’re only blacklisting instead of whitelisting then it would only take 2-3 attempts.
My 2 cents:
~ Twitter Rant
write an app that can read a twitter stream (just one stream): dev.twitter.com/oauth/application-only This is to understand the process of generating an application authentication key. A key that you can REVOKE. The key is used to request a bearer token from the server. A Bearer Token is an access [state] key that expires after 15 minutes. See Section 4.4 of OAuth 2 for Client Credentials Grant
Because you can REVOKE the application key, you can require that users upgrade to the latest version when attempting to validate the purchase. If the application can’t successfully request a bearer token, it can’t communicate with the server license file generator.
~~~~~End Twitter Rant ~~~~~
The Plugin also needs an RSA generated private key to encrypt the communication to the server. This is so the server knows that it’s communicating with a plugin and not with a key generator. Yeah, pirates can crack the application’s private key, but when that happens you simply throw away the public key for that pair and build new app versions with new keys… Just like the Twitter Application Key!
The server should also send a SALT/(NONCE) to the client that should be in all future communications that the client sends the server… Just like a bearer token!
Have the user enter their email address as well as serial number. This effectively switches your server from blacklisting to whitelisting.