I understand that for a server-side product, abuse prevention is easily accomplished by controlling Domain and IP, which are arguably unique for the customer. But this would not work for a client-side product. Is there something else I can use instead? I guess our desktop app can generate a unique random number and have validation locked to it. In that case, we would need to, at the very least, control that field label and string type (or add a new field besides Domain, IP or Directory.
Here are some thoughts on how I think the licensing needs to be adapted for desktop app protection…
LICENSE TO REQUIRE UNIQUE SW/HW IDENTIFIER NUMBER
As mentioned above, locking to an IP or domain would not work for a desktop app, to prevent activating multiple product instances on one license purchase. There will need to be something else, that is unique for a specific installation, and that can be checked against. Like a hardware fingerprint from their computer hardware or maybe a randomly generated number from the app itself, generated upon installation. So customer would need to provide that IDENTIFIER and the KEY would then be generated on the server, specifically for that identifier number.
LICENSE TO REQUIRE CUSTOMER NAME
Licensing to require not only a key but also the name used at time of purchase. So customer will need to enter key and name for license verification. So customers that want to share license with others, will also need to provide their name and that may make them think twice about it. Also, if we detect abuses of a specific license, we will also have the name associated with it. I guess this is not critical but will make someone think twice about sharing the key if their name will need to be explicitly associated with it for validation.
Situations to be accounted for are:
• System to prevent validation from happening if a customer passes their key to someone else
• System to disable expired validations (i.e. when subscription term ends)
• Us to be able to disable validation if abusive behavior noted
• Customer than needs new validation (new computer or installation) to be able to do it themselves, without requiring to contact us for support
• System to invalidate old keys when new keys generated
• Minimize loopholes (e.g. prevent a customer with valid license from generating new keys for others’ unique identifier number, allowing a continuous reset of the grace period… can this be prevented??)
• Dashboard for us to monitor patterns and detect customer abuse (this may be able to address point above)
Activation workflow would be as follows:
1. Customer purchases desktop app from our website, through WHMCS portal
2. WHMCS provides download link for app
3. Customer installs app and unique IDENTIFIER number is generated/displayed for them
4. Customer logs into their account from WHMCS and enters unique number from above (I guess they would enter this instead of entering a domain name or IP address so all we may need to tweak on your functionality is to be able to re-label that field!)
5. WHMCS generates license key
6. Customer enters, in desktop app, NAME and KEY. This will: a) Activate app, and b) Tell app to which account to connect on the server to verify license in future
7. App gets activated for a defined period (e.g. 30 days)
When app starts, it tries to connect to server and see if Name/Key/Identifier are still valid:
• If validated by server, app continues (validation would require NAME/IDENTIFIER/KEY to be correct and payment to be current)
• If denied by server, app stops (and notes that key as invalid)
• If cannot connect to server, a grace period starts (e.g. 30 days + 3 additional app usages) and tracked by app
• If cannot connect to server -and- grace period ended, app stops (and notes that key as invalid)
So, IF [server denies validation] -OR- [app cannot connect to validate and grace period expires] THEN app notes key as invalid and it cannot be used to activate the program again. Customer with a valid subscription can log into the server and generate a new key (steps #4-6 from above). Note this means that the server should be able to generate a NEW (different) key, even if NAME and IDENTIFIER remain the same. (Otherwise I guess the program may need to generate a new identifier once app fails validation.
User (or us) should be able to log into the server and do following operations:
• Change email address or password associated with account
• Enter new IDENTIFIER (New KEY can then be generated, Older KEY will then be marked as invalid, and Changes emailed to customer)
• Find a log of IDENTIFIERS/KEYS/DATES, requests (including IP address of requester) and possibly other changes to their account (email/passwords) to help identify abusive patterns
Is the above business model/workflow supported? OR at least could it be implemented this way using the Licensing Addon?
Question
Strategerizer
I understand that for a server-side product, abuse prevention is easily accomplished by controlling Domain and IP, which are arguably unique for the customer. But this would not work for a client-side product. Is there something else I can use instead? I guess our desktop app can generate a unique random number and have validation locked to it. In that case, we would need to, at the very least, control that field label and string type (or add a new field besides Domain, IP or Directory.
Here are some thoughts on how I think the licensing needs to be adapted for desktop app protection…
LICENSE TO REQUIRE UNIQUE SW/HW IDENTIFIER NUMBER
As mentioned above, locking to an IP or domain would not work for a desktop app, to prevent activating multiple product instances on one license purchase. There will need to be something else, that is unique for a specific installation, and that can be checked against. Like a hardware fingerprint from their computer hardware or maybe a randomly generated number from the app itself, generated upon installation. So customer would need to provide that IDENTIFIER and the KEY would then be generated on the server, specifically for that identifier number.
LICENSE TO REQUIRE CUSTOMER NAME
Licensing to require not only a key but also the name used at time of purchase. So customer will need to enter key and name for license verification. So customers that want to share license with others, will also need to provide their name and that may make them think twice about it. Also, if we detect abuses of a specific license, we will also have the name associated with it. I guess this is not critical but will make someone think twice about sharing the key if their name will need to be explicitly associated with it for validation.
Situations to be accounted for are:
• System to prevent validation from happening if a customer passes their key to someone else
• System to disable expired validations (i.e. when subscription term ends)
• Us to be able to disable validation if abusive behavior noted
• Customer than needs new validation (new computer or installation) to be able to do it themselves, without requiring to contact us for support
• System to invalidate old keys when new keys generated
• Minimize loopholes (e.g. prevent a customer with valid license from generating new keys for others’ unique identifier number, allowing a continuous reset of the grace period… can this be prevented??)
• Dashboard for us to monitor patterns and detect customer abuse (this may be able to address point above)
Activation workflow would be as follows:
1. Customer purchases desktop app from our website, through WHMCS portal
2. WHMCS provides download link for app
3. Customer installs app and unique IDENTIFIER number is generated/displayed for them
4. Customer logs into their account from WHMCS and enters unique number from above (I guess they would enter this instead of entering a domain name or IP address so all we may need to tweak on your functionality is to be able to re-label that field!)
5. WHMCS generates license key
6. Customer enters, in desktop app, NAME and KEY. This will: a) Activate app, and b) Tell app to which account to connect on the server to verify license in future
7. App gets activated for a defined period (e.g. 30 days)
When app starts, it tries to connect to server and see if Name/Key/Identifier are still valid:
• If validated by server, app continues (validation would require NAME/IDENTIFIER/KEY to be correct and payment to be current)
• If denied by server, app stops (and notes that key as invalid)
• If cannot connect to server, a grace period starts (e.g. 30 days + 3 additional app usages) and tracked by app
• If cannot connect to server -and- grace period ended, app stops (and notes that key as invalid)
So, IF [server denies validation] -OR- [app cannot connect to validate and grace period expires] THEN app notes key as invalid and it cannot be used to activate the program again. Customer with a valid subscription can log into the server and generate a new key (steps #4-6 from above). Note this means that the server should be able to generate a NEW (different) key, even if NAME and IDENTIFIER remain the same. (Otherwise I guess the program may need to generate a new identifier once app fails validation.
User (or us) should be able to log into the server and do following operations:
• Change email address or password associated with account
• Enter new IDENTIFIER (New KEY can then be generated, Older KEY will then be marked as invalid, and Changes emailed to customer)
• Find a log of IDENTIFIERS/KEYS/DATES, requests (including IP address of requester) and possibly other changes to their account (email/passwords) to help identify abusive patterns
Is the above business model/workflow supported? OR at least could it be implemented this way using the Licensing Addon?
Edited by StrategerizerFormatting changes
Link to comment
Share on other sites
19 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.