Table security (a familiar problem)

[howardcox]

I am very interested in securing the protection of my data I sell with an application. I sell data with a front end run time search and query application in Alpha 5. I can encrpyt the data table files but even then, a determined user can get the underlying data and import into Alpha knowing the security code to unlock the original application I supply. There is only one level of password protection. I would like a hidden level of encrytion at the table level which is only accessed within the code of the runtime. IS this possible? I am not a programmer but a reasonable expert on Alpha 5. Can anyone simply explain how I can set up the procedure to unlock the application and usage of the underlying table without the user being able to access the tables or import the raw data tables? By the way, I chose Alpha 5 instead of Access because of the fantastic QBE functionality. Its a shame the security aspect is not clear. Please explain clearly in simple stages as what we have to do to overcome this critical issue.

Thanks (any help here will be much welcome) . I have already been give some good ideas by the very helpful Jerry Brightbill of Brightbill Consulting.

Howard
www.keycontact.info

[JerryBrightbill]

RE: Table security (a familiar problem)

Howard,

I have sent you an email directly with more information about an addon I have to do just what you are requesting.

Security is an interesting subject, but for anything to be reasonably secure, it can't be common knowledge. The encyption methods present in Alpha allow a number of different approaches, but all revolve around encrypting the tables with a unique key and then hiding the key somewhere where it can be automatically retrieved. You don't want a public key that has to be entered by the user, since they would now know the key and can decrypt the tables outside of the original application, which is what you are trying to prevent.

Since the security of the key is the issue and not the encryption itself, the method to hide it is the "key" to making it secure.

Jerry

[AaronBBrown]

RE: Table security (a familiar problem)

Encrypting the tables via the security mechanism is pretty dang secure. Like any encryption scheme, if you know the key, you can get into it, but to reverse engineer that would be extremely difficult as we use our own encryption scheme internally...it's not just a password on the data.

[Peter.Greulich]

RE: Table security (a familiar problem)

I can encrpyt the data table files but even then, a determined user can get the underlying data and import into Alpha knowing the security code to unlock the original application I supply.

I am curious as to what you mean? Do you believe that Alpha's table level encryption is not secure? It seems like it is. Do you know of someone (yourself perhaps?) that has broken through A5's security? At least I have never heard of anyone doing that, not to mention Aaron's remarks above. On the other hand, I agree that password protected forms and buttons are not particularly secure, but encrypted tables are another matter.

Peter

[JerryBrightbill]

RE: Table security (a familiar problem)

Aaron

I don't think the issue here is the encyption method, which I agree seems very secure, but the security of the actual encryption key. You need the key to open the tables, so the security is only as good as the security of the value of encryption key. The problem is how to have the program set the encryption key without the end user having access to it. That means it must be available to the program, but can't be found by someone digging in the code or another developer who can open the program. Then the data can only be seen from within the actual database. Even a user who has access to the database can't just attach the data to another databse or open it in Excel for instance and use his database password to get at the data for other purposes. Or course, no one does that.

Anyone who has done work with security knows that security is only as good as the safety of the key. The world's greatest lock is useless if you have the key to open it. Alpha 5 is a very open source type program and most code, even in an aex, is visible to some extent. And if one developer hid it, another can dig it out if they know the hiding method.

Jerry

[CALocklin]

RE: Table security (a familiar problem)

Of course, there is no way to let users see the data in a form and still keep them from seeing it! Or, from cutting and pasting it.

However, assuming you are trying to keep others from doing things like getting into the control panel and running an export, I think the only thing you could do would be to create your own encryption and decryption method then protect the database with it's built-in password method and encrypt each field with your own encryption method as each one is saved/read - one heck of a lot of work and maybe not even possible. That way an export would only export your data as encrypted by your own method. Then you would need to hide the encrypt/decrypt routines within each script or function that uses them and leave all your scripts/functions in the Code tab of the app with password protection. As far as I know, nobody has cracked the password protection on global scripts.

Personally, I don't think all this would be worth the effort. Instead, I'd try to keep users out of the 'guts' of the application so they couldn't export anything unless I gave them a button to do it from.

I suppose you could just not give them the administrator password. Instead, create a user that has full privileges except the ability to change the admin password. (Only "administrator" can change the admin password.) This should be pretty effective at restricting them to only those things you've specifically set up in the app.

Even if they tried to open the table from another app, it wouldn't do any good because they wouldn't know the admin password.

[CALocklin]

RE: Table security (a familiar problem)

Someone wrote me that you cannot add users and groups without the admin password.

So, for anyone who thinks this is a problem, try the A5_user_groups_dialog() command. Or, do as I did and create your own if you want to limit the possibilities. In my case, I wanted them to be able to add new users and select groups but not add or delete groups.

[Charles Brucks]

RE: Table security (a familiar problem)

Ok, How about this. I have set-up the user login screens. I have multiple people using my data and need to lock the customer's records i store to a specific user.
IE
i have users named Tom, Kathy and John. Tom has 3 Customers that are totally his and doesn't want Kathy or John to see/change his 3 customers data. Is there a way to password lock the customers say by referancing the login file.

But by the same token there are 5 Cusatomers they all need to have access to. I'd like to be able to have Tom log in 1 time and have alpha know which customers Toms able to see/edit.

[Peter.Greulich]

RE: Table security (a familiar problem)

Sure. I assume that you gave unique user ids. Add a field to your customer table: "User_ID". Assign the correct user_id to each customer. You could have one "user_id" called "all" or "00000", whatever. Then run a query when the form opens. When the user logs on, assign a global variable to his/her user_id. Set the form query property to: user_id=vUser_ID.OR.user_id="all".

Or something similar.