limit number of installs (2 Viewers)

[Atomic Shrimp]

The big problem with phoning home to activate is that it requires the vendor to support the application into the indefinite future.

That's OK when it's a big corporation like MS or Adobe, who can reasonably be expected to still be trading (and interested in the product) next year, but for a smaller operation, it's less certain, and this uncertainty will translate into reluctance on the part of potential buyers.

 

[Max D]

All the protection schemes are usually a balance between the product's price and efforts needed to break it.

In your case, what prevents user from distributing an MDB file without installer? If user is so dumb it can't find an MDB, almostly any protection scheme will go.

If you are going to sell 1 copy to 1 PC, ud better use activation scheme.
If you are going to sell 1 copy to 1 person, ud better bind it to his email or credit card number - usually people doesn't like to spread this info public-wide.

 

[NigelShaw]

This is an interesting thread.

I have used a phone home system before which worked quite well. However as mentioned, keeping it running as it's downsides.

If you save to a table, there is nothing stopping you reinstalling as the table will be overwritten by the new table.

Again with a property. It's as good as the current version installed.


Another option I had working was a db copied to a separate location during install and this being renamed as a dll. When the main db opened, it checked the location for the dll. If it was found, rename it to mdb, connect to it and get the install data. Do the security thing, disconnect and rename back to dll. If by chance the program crashed before the rename, add a simple handler to search for the mdb too.

I also have with my installer, a registry option to create keys. Although these can be identified by s good hacker, they are generally more accepted during an install rather than when a action is carried out through the db.Your db needs only to look for the key ad thus isn't traced. If the key is there, do your security thing. If the db is reinstalled or replaced, key is still there so security is still in place.

Regs

nige

 

[Alisa]

does anyone have any experience limiting the number of installs of an access solution to one computer with their install packager?

i have something called "advanced installer" that I got from the internet download and I'm wondering how people detect the number of installations that have been done through a package. is this something i can find out in this program that I downloaded or is it windows knowledge that i just don't have? thanks!

From my experience, you are in for a world of heartache going down this road with MS Access. Others have pretty well spelled out your options. My 2 cents is that you should abandon this idea outright. If you really think you have a commercially viable product, invest in coverting it to a real program, like VB.NET. Then you will have some tenable security options.

If that is not possible, I would say give the program away, but sell support (see the MySQL model), or monetize the download page somehow.

 

[Atomic Shrimp]

I agree - because it's considerably easier to implement a time bomb to keep your support customers paying their subscriptions, than it is to implement a limitation on the installation process.

Furthermore, if you are unable, or unwilling to continue developing/supporting the application, it comes to a natural conclusion all by itself when the current licenses expire

 

[Mr. B]

I thought I would just through my 2 cents in on this as well.

I developed an application several years ago that I needed to be able to sell to one user and allow that user to be able to basically have what is called a "site license". This would allow that user to install the software on as many computers as they need to at any one location.

We originally developed this application is MS Access. Later this application was convered to VB5 but we maintained the same type of installation security process that we started out with.

Each installation had a "security" mdb file (one that had a password on the file to open it). In this "password" protected file, we stored specific information about the user. The down side to this entire process was that each security file had to be created for each user to whom we sold the applicaiton. (In today's world I believe that this could actually be handled with a web site where customers could log on.)

Originally this file was placed on a seperate 3-1/2" diskette. Later is was just included on the installation CD. When the application was installed, the user had to insert the diskette with the info on it to complete the installation. Basically what happened was that the information in the "secured" file was written to a specific table in the working database and the secured db file was saved to the installation directory.

On each subsequent startup of the applicaiton the program first checked to see if the security file existed. Then it checked to see that the data in the current working table matched the info stored in the security file. If the data in the working database does not match the data in the security file, the data in the working file is overwritten with the original data from the security file.

Because one of the primary purposes of this applicaiton is to produce printed documentation, and we have the Name and other information about the licensed owner that prints on all output, the process has worked for several years. To my knowledge we have never had anyone to breach our security and share a copy of our software with someone else.

Understand that it may have happened but if it has, it has never gotten back to me.

Just for the record, I, along with one of the Access MVPs, have been working on developing a process that would create a code much like the one that you see when you enter the code to registere a Microsoft product and have that code be used as the registeration for an Access application. We have been hung up for a while due to work load, but hopefully we will get back on track with this soon.

When we have something that we believe will work for limiting installations (at least to one user) we will post more info here.

 

[Alisa]

Just for the record, I, along with one of the Access MVPs, have been working on developing a process that would create a code much like the one that you see when you enter the code to registere a Microsoft product and have that code be used as the registeration for an Access application. We have been hung up for a while due to work load, but hopefully we will get back on track with this soon.

When we have something that we believe will work for limiting installations (at least to one user) we will post more info here.

I would be very interested to see what you come up with. Does your process include "phoning home"?

I am curious because one problem I have run into is that a lot of antivirus software, and even things like video drivers interfere with this type of process when you use encryption.

 

[Mr. B]

I can tell you that right now the plan is to not require "phone home" to activate. However, we have had to make quite a few adjustments to our original thoughts about how this should be done.

Needless to say, it is not a simple as it sounds or everyone would already be doing it. LOL

We will keep you informed when we have anything to report.

 

[ajetrumpet]

here's an idea everyone. this is not great, but it might work to begin with.

using the knowledge I have about internet and VBA manipulation:


when you first open up the program, run an IE window invisibly, goto a webpage and enter an activation key automatically. then write it to a text file and store it on a webserver.

then when the program is installed on another computer, open the same IE window and check the txt file to see if it is already activated. I would do it using PHP and reading text files, but isn't that a possibility? I'm sure it would be, but then again you would have a program running in the background for awhile until it verifies that the installation has not already been completed.

what does everyone think about that idea?

 

[Atomic Shrimp]

That's pretty much what we mean by 'phoning home' - validate against an external authority that keeps track of licences and permissions, etc.

It works, but as discussed above, for the small-time developer, it commits you to supporting the application into the indefinite future and it puts your customers at risk of loss of service if you are unable or unwilling to continue running the validation server.

 

[Banana]

... it commits you to supporting the application into the indefinite future and it puts your customers at risk of loss of service if you are unable or unwilling to continue running the validation server.

Although I have other issues with phoning home, I suppose if I were to use the technique, I'd write in a means of where when I decide to go out of business for whatever reasons, configure my server to send out a special code to permanently unlock the version. That of course means the existing installs would have to periodically check in at a certain interval (say 9 months) so in such situation I only need to have enough cash on hand to afford the hosting for one more year to allow all installs to be fully relinquished to whoever owns them.

Just one way to not make the support continue into indefinite future.

 

[Atomic Shrimp]

Certainly that would be the ethical way to handle planned end of support, but unfortunately, not all one-man-band software outfits end that way - if (God forbid) you fall under a bus, the users are left in the lurch.

Arguably, you won't care what happens to the users in such a situation, but if customers are aware of this risk, it could affect their decision to buy in the first place.

There are other factors that might also wrest the validation process from your control - such as contest of domain ownership.

These aren't such significant risks for the big guys like Microsoft, because they have the support, financial and legal resource to back it all up.

 

[Alisa]

here's an idea everyone. this is not great, but it might work to begin with.

using the knowledge I have about internet and VBA manipulation:


when you first open up the program, run an IE window invisibly, goto a webpage and enter an activation key automatically. then write it to a text file and store it on a webserver.

then when the program is installed on another computer, open the same IE window and check the txt file to see if it is already activated. I would do it using PHP and reading text files, but isn't that a possibility? I'm sure it would be, but then again you would have a program running in the background for awhile until it verifies that the installation has not already been completed.

what does everyone think about that idea?

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.

 

[Banana]

Certainly that would be the ethical way to handle planned end of support, but unfortunately, not all one-man-band software outfits end that way - if (God forbid) you fall under a bus, the users are left in the lurch.

Good points. In the case of unexpected demise, that information should be held in retainer so the estate executor can then release the locks, but still...

Arguably, you won't care what happens to the users in such a situation, but if customers are aware of this risk, it could affect their decision to buy in the first place.

No doubts about that. I'd be apprehensive even if the little guy went to all the troubles of retaining the rights to be released in such events, only to get screwed because estate executor didn't know how to do it, or something equally (or worse!) silly like that.

It may be more preferable to tie the cans to a bigger firm that's been around a bit longer, even though this means you have to compensate the firm somehow.

There are other factors that might also wrest the validation process from your control - such as contest of domain ownership.

Well, technically, I wouldn't use a domain at all but rather IP address as in the theory, if I buy a static IP from my ISP, I'm entitled to the same IP address as long I pay the bill so it would hardly matter if someone else contested and took down my website/domain because it's just a human-readable representation of IP and thus undesirable layer to use for this kind of process which is usually automated anyhow.

 

[Banana]

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.

FWIW- I do not think Access an appropriate vehicle for a commercial application. It's great when you just need some kind of in-house software or maybe as an interface for your clients, in which scenarios, the users already has an incentive to keep the application working and gain nothing from stealing it. Well, at least relatively.

That said, if you really wanted to lock down the application, I'd probably do the following:

1) Use API calls to check the Windows logon and whether the computer is a member of certain domain. Best to call the Domain Controller so there's no need to embed any information about the domain itself in the application. Just need to match the data from API calls to the DC's description of the computer. This by necessity requires VPN for external connections as well. Even if we don't have AD, something similar can be setup.

2) Don't store data in Access at all. Use a server RDBMS such as SQL Server, Oracle, DB/2, MySQL, PostgreSQL, whatever and require log-on by the users so the password isn't stored. The user & password shouldn't be stored and can be enforced in both client & server by using DSN-less connection for the client and implementing MSysConfig table in server.

3) Convert to MDE/ACCDE/ADE.

Few more points:

1) It's not that Access security is flawed. It's simply the nature of having a file-based database. An application compiled in Visual Studio using SQLite or SQL Server Compact Edition would have precisely the same problem. This is because the direct access to the data file is required so it's only a matter of cracking the protection. Server RDBMS circumvent the problem entirely by having a daemon manage the data files and thus users do not require access to the data file to use it- they just need to interact with the daemon. Though doing it in Visual Studio would have more flexibility in how to implement the protection, it still doesn't change the fact that we're just delaying the inevitable.

2) It's actually easier to decompile an .exe than it is to decompile a .mde/.accde/.ade. This is because the decompiling for machine code or .NET CLR are documented and more widely known whereas there is no public documentation at all for the VBA's p-code (e.g. the compiled code) and there's certainly no symbol table available. So IP relating to VBA code is actually quite well-protected. Of course it's still up to us to protect the tables & queries.

3) We can further restrict the access to the data by configuring the network in such that it only accepts connection from a certain family of IP addresses so it need not be exposed to the whole company's network or even the internet. This step, of course, is probably mandatory for any reasonable security setup, even if the company is totally uninterested in securing the database and trusts the users.

EDIT:

4) Many of protection schemes I've seen around usually miss this crucial point: The keys, passwords, whatever, are always stored plaintext whether you store it in a table, in VBA as a string literal or as a object's property. Thus that information can be gotten by merely opening Notepad on the file. Some may attempt encryption but encryption by design is two-way, so it can be crackable. If it must be stored, use a hash instead. The description in #1 illustrate the point of not storing by doing a comparison between two different calls into Windows' API, one against the logon and other querying the DC. VBA code needed to do this can be protected much more effectively than when it has to compare with a value in table, in a object, or a string literal.

5) I've posted it before but I'll do it again because it's worth emphasizing:

So even if we had 4096-bit RSA or the top-of-line encryption available to us, it doesn't guarantee that hackers will not find an easier way to get the information.

END EDIT

So, yes, Access, like any other programs & files can be secured. It actually depends more on the operating system & the network rather than within the file itself. After all, Excel & Word's "protection" suffer from exactly same problem- the password are stored inside the file and is thus available for taking.

 

[Alisa]

FWIW- I do not think Access an appropriate vehicle for a commercial application.

Bingo.

You can spend all the time in the world trying to lock down an Access application, but at the end of the day, your time would be better spent upgrading to a solution that is appropriate for the scenario.

 

[Pauldohert]

I have design features that mean users never even try to install my apps again. Let alone do.

 

[Alisa]

I have design features that mean users never even try to install my apps again. Let alone do.

Obviously you won't want to discuss exactly how this works in a public forum, but I am curious about how you accomplish this. For instance, once your program is intalled on one computer, what stops someone from simply copying the mde, backend, etc. to another computer?

 

[Pauldohert]

Obviously you won't want to discuss exactly how this works in a public forum, but I am curious about how you accomplish this. For instance, once your program is intalled on one computer, what stops someone from simply copying the mde, backend, etc. to another computer?

They are able to - its the desire they lack.

 

[Alisa]

They are able to - its the desire they lack.

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.