Anyone Interested in an A5 DB Security Add-in ?

[brett s]

RE: Anyone Interested in an A5 DB Security Add-in

Yes, I am very interested. But first let's make sure we are talking the same language here.
What I, and I believe many other Alpha Five developers, will want is a way to protect their intellectual property rights as represented in a Alpha Five application that they have developed. Therefore, I want these two things:
1. my Alpha Five source to be protected against unauthorised disclosure and modification and/or re-use; and
2. my Alpha Five application protected against unauthorised duplication and re-use.
And I want these two things done without excessive intrusion into my customers fair use of my application. So, for example, I consider product activation (a la Microsoft's model as implemented in Win XP and Office XP) to be overly intrusive from my customers' viewpoint and, from my viewpoint as the developer, administratively excessively cumbersome, so I don't want this.
How do I see application protection working then? I think protection based on a product registration id (unique to each copy of my application) combined with a customer supplied phrase (personal name, company name, email address or the like) to generate a secure non-reproducible registration key (which might be a hex code 30 digits in length for example) would probably work OK. It needs to be supported by a process to enable developers to record the registration details of their customers. So an Alpha Five product registration database application will be required here. (A business opportunity for someone?)
There will also need to be a way of presenting a "trial version" registration id so that all features of the application may be used for a set period, say up to 15, 30, 60 or 90 days and then selected features disabled until a valid registration key is supplied following purchase.
I'll stop here. Hopefully, someone from Alpha Software will read this and provide some more details on how they are proposing to implement application security and registration so we can be sure we are all talking the same language.

[CALocklin]

RE: Anyone Interested in an A5 DB Security Add-in

Brett, I tried to e-mail this to you but it wouldn't go through.

I read your post on this subject with great interest. I've created something like that for one of my applications. However, it's unique to that app and not suitable for general distribution - at least, not yet.

The one big struggle I had was with a time limit on the Trial Version and I would like to hear comments on the subject....

I ended up protecting my app by limiting the maximum number of records in a "key" (as in "important") table. I did not set up any limit based on time because the only method I could figure out for doing this was by writing to the registry and there are numerous programs that can track registry changes thus making it possible for someone to determine what was written, delete it, and start over again.

- Has anyone put any thought into this and come up with a more foolproof method for restricting the time?
- How big of an issue would you consider these registry trackers? Would you go ahead with a time restriction based on the registry and take your chances on someone figuring it out? Combine time with a higher record limit just in case? Add a fake file to the Windows folder? Other ideas?

I once created an app with an internal date limit that I had to set before I sent out each trial copy but that can quickly get to be a ridiculous system - especially if a lot of people want a trial version. And, of course, that trial version can't be given to someone else a few months later because it will no longer function.

[Stephen Williams]

RE: Anyone Interested in an A5 DB Security Add-in

Have you thought of using a simple table to track registration info and encrypting it? Only accessable by xbasic within the app. I don't know enough about encrypting and decrypting.

Or use the registry to store the date, but also create a file whose name is encrypted. You need both the date and file name to get access. If the registry raiders mess with the date the file won't decrypt, and they will have to get back to the programmer for a new code on the file name. Or reset the date in the registry...

I am sure there is a way.

[JerryBrightbill]

RE: Anyone Interested in an A5 DB Security Add-in

Your ideas are very sound and most successful methods use a combination of information saved within the application and info saved in a second location such as the registry. If the methods also include encryption, then it can be very difficult to determine the exact method to defeat the security. The key is that determining how it is being done must not be easy or obvious.

The method also has to be such that reloading the original program does not reset the security. If you have a time limited demo and a reload resets the time, then defeating it is very simple. Just reinstall. Relying on a table or information saved only in the database doesn't work.

Time limited demos are fairly easy if there is a secure way to save the first time the program is opened. Some programs also limit how many times you can open the program before it locks or requires registration. That also requires saving information in a secure location. Time limiting can frequently be defeating by continiusly resetting the computer date, but that becomes a real pain.

The problem with most methods are that they are very specific to one application. Developing a method that can be used as an addon is much more difficult. Once any "developer" purchases the method, they have most of the keys. They can see what is being modified and where. Then they can unlock applications made by others using the same method or by knowing what can be done to defeat the security.

I have also been working on, and using, a method that uses user specified encryption. The developer sets the encryption key. If the key is lost or forgotten, there is no method to retrieve or interpret the security. The information locations are multiple and difficult to locate.

With enough work, nearly any method can be defeated. The question is, how difficult does it need to be?

Jerry

[mronck]

RE: Anyone Interested in an A5 DB Security Add-in

Hi Jerry,

I read your wise comments.
The question how difficult it needs to be seems the key here.

I am not a security expert, but as I see it, someone using a copy of your software without a license has to get it somewhere else then from the developer.
So when somebody gives his software to an acquaintance, what's stopping that somebody to also give his licensenumber?

So in that case, what would your high effort security add to prevent this ? As I see it, nothing.

What I do is implement a licensenumber in applications that shows up in all communications between users of my apps and myself. In that case, security software on my server autodetects who the initial buyer of the software is and I can act as I see fit.

So I choose to control the active lines between my applications and myself (like technical support, updating services etc) rather then trying to stop illegal copies.
Practice learns that it is almost impossible to stop it anyway unless hardware solutions are implemented, so why waste the time ?

Furthermore, if your apps are updated rather quickly, you in this way "outrun" the illegal copier, because the moment he has his software copied, a couple of weeks
or months later it will already be obsolete and he has to do it all over when he wants to be update.
And the market value of an obsolete product is not as nearly as high as the actual legal version.

Just some thoughts....

Nevertheless, a built-in solution for licensemanagement would be nice although every developer already will have built a solution for himself I guess....

Kind regards,

Marcel

[JerryBrightbill]

RE: Anyone Interested in an A5 DB Security Add-in

Marcel

All very good points. There are actually a couple related security issues here. One is protecting code and proprietary operations. A5 already has good tools for that. Password protect everything, move all scripts and functions to aex files, and encrypt any sensitive data. It won't eliminate "borrowing" code, but it will make it much more difficult.

The second issue, which is one you addressed, it how to limit a fully functional program to licensed users. As you point out, any method is relatively easy to defeat. All you need is the license number. The only real limit is that you can restrict access to updates and support to only those who are listed as registered. But if they pass it on....

The third area is handling demos or restricted use versions. Here there are 2 basic methods. One is to produce 2 versions. One version has restrictions and time limits hard coded and the other doesn't. The problems with this are many. You must maintain 2 copies, the demo may need configured every time it is distributed (date change, etc), and the fact that the user has to get a completely need copy of the program to get the fully functional version. This may require a CD or a large download. If the demo allows saving real data, this may not be acceptable.

The second demo method is to use some type of security to limit functionality. The user enters a key to unlock the program. This is simplier, but less secure.

The problem with many methods is a false sense of security. If the method is generic, it probably can be defeated. Then was it worth the effort? It is like any security, the very determined will find a way around it.

Jerry

[CALocklin]

RE: Anyone Interested in an A5 DB Security Add-in

This has been a great discussion!

If the time limit or record limit is hard-coded in the app, why not just have a routine that checks for a proper registration code within various key scripts? It could then set a variable, encrypted file, saved setting, or some combination thereof that would by-pass the limit when a proper registration number has been entered. This would eliminate the need for two programs.

Better yet, kill the program if a wrong registration number is encountered. That would keep someone from figuring out the appropriate variable or setting and bypassing the registration number. Enter the correct 'variable' with either no registration or a bad registration and the program quits at some key point. Tie the registration number to the computer (not popular but effective) and the app becomes pretty well protected.

[JerryBrightbill]

RE: Anyone Interested in an A5 DB Security Add-in

Cal

There are many ways to look at security. If you are working with a custom, limited distribution program, you can hard code various locks directly into the program. The problem is that each copy is somewhat unique and the developer has to hard code each copy.

The second situation is a generic, wide distribution program, where there may be many copies. Hardcoding each copy becomes a logistic challenge. In this case, you need a method that is easier to apply and manage.

Both situations have the problem of where to save the critical information. Files, saved settings, registry entries, even code can be examined and viewed. Encryption can hide a lot, but there still has to be an encryption key somehwere.

The discussion started on the concept of an addon, which suggests a generic, not custom method. I have no problem coming up with a method that works well enough for individual databases. But developing a generic system that is relatively secure is a different challenge.

Jerry

[mronck]

RE: Anyone Interested in an A5 DB Security Add-in

Hi Jerry, Cal,

The security you search is indeed very much effected by the type of software you create and the market you sell it on. An example of my past:

A few years ago my team developed a software program that was sold thousands and thousands of copies all over the world. Our clients were almost not individuals but all companies of the larger kind and institutions.
Some of my clients: The White House, US-Navy, Wells Fargo Bank, Boeing. Just to get an idea.

However, my market appeared to be one of only a few sellers and lots of buyers.

In this case, we proved to have the better product in the market, so we became the leader in the market.
Clients approached us for improvements and enhancements and we marketed lots of versions.

We had security built in, but not very sofisticated security, just basic.
But we came on the market with new versions rather quickly, so it was not worth it for pirates to invest a lot of effort to 'steel' the software: it would be obsolete when they were ready and the market value would be not worth it.

What we did was check the internet on any strange product anouncements on our product.
Sometimes we ended up at Russian servers. But, unexpected, all the webmasters were at once ready to help us.
The illegal sellers got a warning to remove the illegal software or they would shut down the site. We followed what happened, and in all cases the software was indeed removed.

So, the point of this (too long) story is to bring in the discussion the point that in stead of trying to do the impossible you could also fight the ones who steel your code to keep the offer of illegally copied software as low as possible.

Kind regards,

Marcel

[Martin Boulonois]

RE: Anyone Interested in an A5 DB Security Add-in

Sounds great, what is the price of this?

[CALocklin]

RE: Anyone Interested in an A5 DB Security Add-in

That was just a question to get an idea about the amount of interest. "It" was never developed - at least not yet.

Some of us have developed our own methods but (a) it takes a lot of time to develop and (b) I, for one, do not relish the idea of giving out my security methods so somebody else can create registration numbers for my applications.

[Mark Buonagurio]

RE: Anyone Interested in an A5 DB Security Add-in

Very interested. More info and pricing please.

[Gregory R. Zilliox]

RE: Anyone Interested in an A5 DB Security Add-in

Yes, very interested.

[howardcox]

RE: Anyone Interested in an A5 DB Security Add-in

Yes I am very intersted. I sell data with a front end run time search and query application in Alpha 5. I can encryt the data table files but even then, a determined user can get the underlying data and import into Alpha knowing the seciurity code to unlock the original application. There is only one level of password protection. I would like a hidden level of encrytion at the table level which is only accessed withinthe code of the runtime. IS this possible.

Thanks (any help here will be much welcome)

Howard
www.keycontact.info

[Andy Dibble]

RE: Anyone Interested in an A5 DB Security Add-in

Bret,
Good comments.

Another security requirement could be annual licence registrations. For example. I use CAD Planning software that has an annual licence fee, which must be paid if I want to continuously use the software.

This could ensure continuous earnings from our applications, it does not need to be huge $ amounts - just enough to warrant further application and service requirements for the supplied application. Can the software be developed to reduce access to the program? (Not the data just the application)

In exchange for the continued licence fees you could provide free updates and enhancements etc for the following paid year.

Some people may think this the wrong way to market your applications, but at the end of the day � you and the client will negotiate you�re own contract that is acceptable to both parties, this can include an annual licence agreement that can earn you more revenue.

What about adding Dongle Security in Alpha Applications? Many software suppliers now use these dongles to ensure no illegal copying and networking use can take place! I for one would be interested in protecting my applications with these devices. I believe they are extremely difficult to duplicate.

Regards
Andy