-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Features Requests / Possible Bugs #5
Comments
Examples of the above User: sam
User: paul
Machine: peanut
Machine: raisin
|
Yes this, this is intentional. Anyone can rename their computer or user name on a machine. Machine name and username are only memo fields to help you with fraud detection to who is using your software and on what machine. The only way to really prevent key stealing would be to seed an activation hash using hardware IDs and the activation key on the licensed machine and upon first activation, store that on the DB side and on each check, send the hash and make sure it matches what was sent for the first ever activation. The problem with is if it’s hard coded into a public library, anyone can come to this repository and see how it works and crack your software. I do have a Client-Side library for this on the TODO list but it’s not done yet. This is why the username and machine name exists, to help you manage fraud in the meantime. |
You can achieve this with the hwid parameter. If supplied, the key can only be checked on that one machine. I will have to come back around and store multiple activations on the same key in a table to allow one key to be used on multiple machines. |
Not sure if this is intentional or not, but the validation seems borked
After activating the the token (specifying a machine and user), neither are used in the validation (check) steps, thus it is possible for user paul to "steal" user sam's token, and still have activated software. Additionally, the software can be installed on multiple machines (with different machine names) and still return as license ok
A quick way to resolve this might be to have the activations stored in the db, and verified agains an active user (by using a foreign key or many-many to the users table), and having the api/check validate it against this table
HTH
The text was updated successfully, but these errors were encountered: