limit number of installs

Right, well now we are back to what is appropriate for different scenarios.
If you are attempting to sell a commercial product, then there is incentive to get it for free.

I was joking.

But I do use a self generated activation code - that quite frankly even an expert would do better spending their time doing something else rather than hacking.
 
I was joking.

But I do use a self generated activation code - that quite frankly even an expert would do better spending their time doing something else rather than hacking.

Well it is pretty easy to have a code that is too much trouble to hack. The issue is how does the Access application know that the activation has occured, and how do you keep people from fooling the application into thinking that the activation has occured? For instance, if you do the activation and then copy the mde to another computer, how does the mde KNOW that it shouldn't work anymore?
 
A simple solution would be to store a hash value of activation key + .mdb's path + computer name (or something similar) + salt into a database property.

That way, it's not exposed via tables, and not so easy to find and even if found, cannot be reversed. Copying the file would then produce a broken copy. Of course, it could be very inconvenient to the users when they find out they can't move it at all!
 
A simple solution would be to store a hash value of activation key + .mdb's path + computer name (or something similar) + salt into a database property.

That way, it's not exposed via tables, and not so easy to find and even if found, cannot be reversed. Copying the file would then produce a broken copy. Of course, it could be very inconvenient to the users when they find out they can't move it at all!

So what's to stop them from running the installer on another computer with the same activation key? How does the prepackaged program know that a particular activation key has already been used?
 
I thought we were talking about 'phoning home' scenario in where activation key is given by an external source?

But anyway- if we're going to not phone home, the installer would need a list of hash for which activation code has to be given by email and thus hashed and then match one of hash on the list, which then gets deleted from the list.

This of course imply that the installer itself probably would have to be a custom built one...
 
Well it is pretty easy to have a code that is too much trouble to hack. The issue is how does the Access application know that the activation has occured, and how do you keep people from fooling the application into thinking that the activation has occured? For instance, if you do the activation and then copy the mde to another computer, how does the mde KNOW that it shouldn't work anymore?

Well - I use the computer name and date and domain of the database - which should match a key in the BE.

Someone could fake all those - then crack the code - but its unlikely they could or didn't have better things to do.

-

Problems occur when valid installations change - but by then - they have paid enough that I dont mind the couple of minutes work to issue new codes without payment.
 
I thought we were talking about 'phoning home' scenario in where activation key is given by an external source?

But anyway- if we're going to not phone home, the installer would need a list of hash for which activation code has to be given by email and thus hashed and then match one of hash on the list, which then gets deleted from the list.

This of course imply that the installer itself probably would have to be a custom built one...

Having a custom built installer kind of means you aren't doing a commercial distribution, right?

If you do a phone home scenario, if you don't encrypt the communication, there is nothing to stop someone from sniffing out the calls to your server. They could then use that information to write their own connection to your database server and hack your data. (Presumably, your code will connect to your server and read the data in there to find out whether a code has been used before).

If you do use encryption, then you run into problems with people not being able to complete activation because their antivirus software interferes.

I just think there are no good options.
 
Wait a minute- antivirus interferes with comparing hash values? I've done that in a old project and there was no complaint from our anti-virus program.

Note that hashing != encryption.

As for the phoning home scenario whether the connection is encrypted or not should be immaterial- See public key cryptography.

As Pauldohert pointed out, it's really a factor of whether the hacker-to-be really that data badly so he's willing to go to all the trouble. If the data is some past financial reports then the interesting-level of data is going to be so low that they'll decide to hack into DoD website instead and activate the nuclear missiles instead. </tongue-in-cheek>
 
It is really hard to make this work. Where does the activation key come from? How do you prevent keys from being reused? What happens when your customer doesn't have an internet connection? How does the program know whether it has been activated or not? How do you prevent people from fooling the program into thinking it has been activated?

My conclusion with regards to access (would love to be proven wrong by the way) is that the only viable security model is "security for show". Like when people play a recording of a barking dog in their house and have lights on timers when on vacation. With access, you can make it *look* secure, but it is trivial for anyone with motivation to circumvent your procedures.
the people were are marketing for do not have this motivation. and also, like I said before, registrations would be stored in a text file on the server, and any future registrations would be check against the entries in the text file and then appropriate action would be taken. is that difficult you think?

there is also no way to "FOOL" the program unless you can get into it with all the normal security features taken, because the program runs the installation instructions on startup before anything else takes place.
 
It is really hard to make this work. Where does the activation key come from? How do you prevent keys from being reused? What happens when your customer doesn't have an internet connection? How does the program know whether it has been activated or not? How do you prevent people from fooling the program into thinking it has been activated?

My conclusion with regards to access (would love to be proven wrong by the way) is that the only viable security model is "security for show". Like when people play a recording of a barking dog in their house and have lights on timers when on vacation. With access, you can make it *look* secure, but it is trivial for anyone with motivation to circumvent your procedures.

Alisa,

I think I found a solution. Here's the code:
PHP:
Function CheckForValidation()

If DLookup("needvalidation", "validate") = "no" Then
    GoTo OpenProgram
End If

    If IsNull(DLookup("needvalidation", "validate")) Then
        DoCmd.OpenForm "frm"
            Exit Function
    Else
        GoTo OpenProgram
    End If

OpenProgram:

'DO THE OPENING PROGRAMMING STUFF HERE

End Function
PHP:
Private Sub ValidateButton_Click()

DoCmd.Hourglass -1
DoCmd.SetWarnings False

Dim db As Database
Set db = CurrentDb()
Dim rs As Recordset
Set rs = db.OpenRecordset("validate", dbOpenDynaset)

Dim ie As Object
Dim address As String
Dim StopTime As Variant, start As Variant

Set ie = CreateObject("internetexplorer.application")

address = "http://YOUR VALIDATION PAGE"

      ie.navigate address
      
         While ie.busy And ie.readystate <> 4
            DoEvents
         Wend

start = 0
StopTime = 10000000
   While start < StopTime
      start = start + 1
   Wend

      'SEARCH FOR INDIVIDUAL LISTINGS OF THE CATEGORY HERE
      ie.Document.all("key").Value = Me.TXT1 & Me.TXT2 & Me.TXT3 & Me.TXT4
      ie.Document.Forms(0).submit

         While ie.busy And ie.readystate <> 4
            DoEvents
         Wend

start = 0
StopTime = 10000000
   While start < StopTime
      start = start + 1
   Wend

If ie.Document.all("Confirm").Value = "true" Then
    MsgBox "This license has already been registered." & vbCr & vbCr & _
           "You may only register a license one time...", vbCritical, "Validation Error"
                Application.Quit
Else
    rs.AddNew
    rs!needvalidation = "no"
    rs.Update
        MsgBox "Product Now Validated.  Thank you!"
            DoCmd.Close
                'RUN THE REST OF THE OPENING CODE HERE THAT YOU NEED TO
End If

cleanup:

ie.Quit
Set ie = Nothing

DoCmd.SetWarnings True
DoCmd.Hourglass 0

End Sub
Here's the webpage code that I used:
PHP:
<?php

//If the key is blank, go on to the HTML section
if (! $_POST["key"]) {
	//DO NOTHING
					 }
else
{

$validation = "false";

$logfile = "validation.txt";

//Read file for creating final report
$handle = fopen($logfile, "r");

//If there is no information in the log, display a message and exit
if (filesize($logfile) < 1) {
	$validation = "false";
	fclose ($handle); }
	
//Otherwise, print the report!
else {

$log = fread($handle, filesize($logfile));
fclose ($handle);

// Seperate each logline
$log = explode("|", trim($log)); 

// Seperate each part in each logline
for ($i = 0; $i < count($log); $i++) {
	if ($log[$i] == $_POST["key"])	 {
		$validation = "true"; }
									 }
									 
	 }

if ($validation == "false") {
    
	$handle = @fopen("Validation.txt", "a");
    fputs($handle, $_POST["key"] . "|");
    fclose ($handle);
	
							}
	
}

?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"... 
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Validation Log</title>

</head>

<body>

<form action="" method="post" name="frm">
  
    <center><br />
      Enter Your Product Key:<br />
        <input type="text" id="key" name="key" /><br />
        <input type="text" id="Confirm" name="Confirm" value="<?php echo $validation; ?>" />
        <!--<input type="text" id="Confirm" name="Confirm" />-->
    </center>
  <p>
    <label>
    <center><input type="submit" id="valcheck" value="Validate" /></center>
    </label>
</p>
</form>

</body>
</html>
 
It looks like you have a good start, I hope it works well for you.
I may not be understanding your code properly, but it looks like they could enter any value and as long as that value hadn't been entered before, it would be valid.
 
but it looks like they could enter any value and as long as that value hadn't been entered before, it would be valid.

that is correct Alisa, and the way we get around that is to give a product key that comes with the product already embedded into the form. The product is inside an installer, and the product key is checked the fist time the program is opened and never checked again. Thus, if you try to run the installation packager on two machines, the second one will deny you because it has the same embedded key code in it, and it's already logged in the text file. I thought it was a pretty good idea!
 
So every customer gets a unique installer?
 
So every customer gets a unique installer?

that's correct. we generate the product key in the access database, and that's where it stays. pretty cool huh? thus, you cannot run the installation packager on more than one machine and get away with it!
 
that's correct. we generate the product key in the access database, and that's where it stays. pretty cool huh?

Yes, thats a creative solution, but not really what I'd call a commercial distribution . . . what if you wanted to sell 5000 copies, that would be a ridiculous amount of work!
 
actually, I could write a procedure to open 5,000 copies of the database and put the needed information into it automatically with a key generator, but writing the code ONE TIME would sure be a pain in the butt!
 
Also, what stops them from copying the mde to multiple computers after activation?
 
Also, what stops them from copying the mde to multiple computers after activation?
you can do this in any number of ways. the easiest is probably to check appliction.currentuser in code. If it's different than the one put in the table when its registered, shut it down. That's what I do now, which tells you the owner of the PC. I believe that's what it reads.
 
Sounds like you've got it pretty well worked out - I hope your deployment goes well.
 

Users who are viewing this thread

Back
Top Bottom