Require login before showing GUI and running script? - (Moved)

[orbs]

that topic has been discussed many times in this forum - your AutoIt source code is not safe against a determined hacker. you can install a licensing feature for the ordinary user, and your EULA can forbid decompile or reverse-engineer your code; but that is not technical means of protecting your code.

now, stop whatever you're doing and go read the forum rules. article 1, bullet 6. and the rest too, while you're at it.

[Nick3399]

Hi Orbs, I keep getting errors with the Login script that you sent over and it looks like it is very outdated and no longer supported - are you aware of anything newer that still works? 

[Earthshine]

Honestly your best bet would be to use something like this 

https://www.cryptlib.com/security-software/licensing-structures

[orbs]

@Earthshine, i can't see how that can be useful. care to elaborate?

@Nick3399,

first, please take care of the terms you use. for example, when you say:

3 hours ago, Nick3399 said:

... the Login script that you sent over ...

and you refer to neither a login script nor anything i sent you, that may be seriously misleading.

now, the XProTec UDF - like any other UDF - may be in need of revision once in a while as the core of AutoIt changes, but that's no reason to not follow a reasonable troubleshooting routines - your ambiguous "i get error" posts won't get you anywhere.  if you are honestly seeking help with that UDF, you can post a detailed description of the error, as well as the part of your script that triggers the error, in the topic of the UDF. if the author of the UDF does not help you, other users of the UDF might. but you are expected to show some effort, and detailing your issue is the first step.

UDF aside, when it comes to licensing, i would not blindly trust a UDF without reading and understanding it. to my understanding, your case is different from the UDF purpose, enough to justify writing it yourself. if i were you, this is what i would do:

first, create a web site with a database of a single table of 3 fields: user name (preferably email address, i'll explain shortly), a hashed password, and a creation/purchase date.

if you insist on user/password authentication, you must think of the scenario where a user forgot his password. you can have a button (in your program) titled "reset password", and your database server can generate a random password and deliver it to the user - how? by email, of course. so you must store a valid email address, and since that is unique to a user, no reason to create a user name, just use the email address as the user name.

next, learn some PHP so you can write a server-side API to your database. that is a lot simpler than you might think, since your PHP code needs to do basically two things: 1) receive a creation command, and 3) receive a credentials set and return the creation date.

finally, add to your AutoIt program the ability to communicate with that API.

now i know that was a long post and seems rather complex, but once you get your hands on it it's not that bad - and most importantly, when your customers ask for your help with a licensing issue, you'd better be well acquainted with the licensing system you use!

 

Edited November 25, 2018 by orbs

[Nick3399]

Hi Orbs,

 

Thank you for your response - it has been very helpful! I went ahead and created a Database via a webpage, and created a PHP file on the webpage that connects to the database and I tested the connection as successful. Now I am trying to figure out how exactly to connect that php file on my webpage to the autoit script to create/read the info.

[Nick3399]

So I am stuck with this now - I am using 000WebHost to create the MySql database and create the PHP file like so:

<?php
$servername = "localhost";
$username = "XXX";
$password = "XXX";
$database = "XXX";


try {
    $conn = new PDO("mysql:host=$servername;dbname=$database", $username, $password);
    // set the PDO error mode to exception
    $conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "Connected successfully"; 
    } catch(PDOException $e) {    
    echo "Connection failed: " . $e->getMessage();
    }
?>

I am getting "Connected Successfully", but now I guess that is PDO - Does Autoit even work with that? When I try to query on the PDO with a Select, I am not getting anything 

[orbs]

here's how you go from here: your AutoIt program uses InetRead() to submit a user ID and hashed password as arguments to your API. assuming your API is a PHP file named "licensing.php" at the root of your web site, it's something like this:

http://yourwebsite.com/licensing.php?user=user@mail.com&hash=b4b992ad

your PHP code retrieves the arguments like this:

$sUser=$_GET['user'];
$sHash=$_GET['hash'];

then your PHP code performs a query against the database to get a match for the given credentials set. if none found, then it means that the user wishes to create it - your PHP code then inserts a new row to the database, with the given credentials set and the current creation date. if a single row was found, your PHP code returns the creation date to the calling script, then your script calculates the time difference and decides how to proceed (if more than one row was found, then something went terribly wrong).

 

Edited November 26, 2018 by orbs

[SolemnStrike]

I "solved" the Problem like this btw:

- takes Hardware id 

- encrypt hardware id

- downloade .txt from my Dropbox etc

- read the .txt and check if the encrypted hardware id is in there

If yay then you can pass,

If nay then it will show the encrypted hardware id (and put it in the clipboard) so the user can send me his money and the encrypted hardware id and ill add it to the list then.

 

Why i used this method even tho its less save than a php site etc? 

Because if someone sniffs the downloaded .txt he has to decrypt or encrypt a hardware id first with my algorithm.

To get my algorithm he has to crack my program first.

And if he managed to do this, he could also simply remove the whole login part anyway, thats why its pointless to try to make it more serverbase imo (maybe i forget something tho)

[orbs]

yes, that works too - for your scenario. however, given the OP unexplained obstinacy regarding the login requirements (i.e. user name and password), your solution is hardly the best one around. moreover, i'm curios to know how do you plan to handle a request from a user to transfer your program to another machine? or to a virtual machine?

you are correct assuming that a determined hacker (or even a savvy user with malicious intentions) can get their hands on your code and manipulate it as they wish. that is no reason to skip basic precaution measures, like - for example - not revealing everyone's info to every single user asking for it! no matter how hashed, encrypted or useless that info is.