Question Protect ACCDE (1 Viewer)

[mcdhappy80]

I have a security system in my application that depends on one custom property in which I store licence which my application uses in order to work.
I've just found out that I can open this property (from another access database, even when the database containing the property is in an accde format) and change it!
My question is can this somehow be prevented?
Will I make things better if I move property from database to registry key file?
Any ideas on this subject (make the accde completely unusable for abuse) would be appreciated?
Thank You

 

[DCrake]

Did you manage to get the property because you knew the property name? How would a person know about the property in the first place in order to extract it.

 

[mcdhappy80]

Did you manage to get the property because you knew the property name? How would a person know about the property in the first place in order to extract it.

Yes, of course I knew the name, but that's not the way I could find it. I could find it by creating a loop trough db properties and it displayed itself there.
Even if a person don't know the name he can loop trough the properties and find it via elimination process (I suppose he can read about the default db properties on internet and the one that doesn't match on the list would be mine custom).
So I guess the properties are not safe for storing info after all?
Any other ideas?

 

[boblarson]

So I guess the properties are not safe for storing info after all?
Any other ideas?

They are safe for 99% of the people out there. If you want to get it to 100% then you are using the wrong tool. Access is not secure and if someone wants to hack your stuff, they will figure it out.

But, just to make it slightly more difficult for them, I would

1. Not store the value in the property in plain text form. I would use an encryption method to encrypt the data and store it there. Then, someone would have to know how you encrypted it.

2. The encryption code can be included in your modules which can be compiled so that it is not readily available.

3. The property name should not be something that makes sense from a person reading it. If you want to store your registration key there, you could call it something like FormActivate. Which then if you include a few other properties with some bogus encrypted data, will make it even harder for them to figure it out.

The main thing to note here is this. Even Microsoft gets their software hacked and keys generated. So, you aren't any more special. Except, that you have one thing going for you. You are not passing this out to a large user base (I'm guessing) and if you encrypt the data, then you don't have to worry about 99% of the population. And if you don't encrypt it, you probably don't have to worry about 90% of the population.

 

[mcdhappy80]

They are safe for 99% of the people out there. If you want to get it to 100% then you are using the wrong tool. Access is not secure and if someone wants to hack your stuff, they will figure it out.

Which is more secure development environment than access?

But, just to make it slightly more difficult for them, I would

1. Not store the value in the property in plain text form. I would use an encryption method to encrypt the data and store it there. Then, someone would have to know how you encrypted it.

I was using some code example that does some encrypting on text string by rotating the characters in it, but I had problems with it, because when I generated encrypted licence on my machine, it decrypts it wrong on the user machine. Maybe because the different version of Windows?
Do You have some reading to guide me to create encrypted licence in access VBA?

3. The property name should not be something that makes sense from a person reading it. If you want to store your registration key there, you could call it something like FormActivate. Which then if you include a few other properties with some bogus encrypted data, will make it even harder for them to figure it out.

Hm, didn't cross my mind, thnx

The main thing to note here is this. Even Microsoft gets their software hacked and keys generated. So, you aren't any more special. Except, that you have one thing going for you. You are not passing this out to a large user base (I'm guessing) and if you encrypt the data, then you don't have to worry about 99% of the population. And if you don't encrypt it, you probably don't have to worry about 90% of the population.

I have to agree with You on this, but it is my job to do everything I can to do things right. (hope You agree with me on this? )

Thank You guys for Your answers.
Cheers!

 

[boblarson]

Which is more secure development environment than access?

VB.NET, C#.NET, etc.

I was using some code example that does some encrypting on text string by rotating the characters in it, but I had problems with it, because when I generated encrypted licence on my machine, it decrypts it wrong on the user machine. Maybe because the different version of Windows?
Do You have some reading to guide me to create encrypted licence in access VBA?

No need to get all fancy with encryption. You can use this simple function to encrypt it because, as I said, you are not going to stop people if they are persistent enough. But this will do for 95% of the people out there. See the sample database I threw together in a few minutes to give you an example. You could run the reg info through the encryption part and store it in the property like you are. Then when you need to check it, you run it back through the decrypt function.

 

[Banana]

VB.NET, C#.NET, etc.

Actually, I'd say they are actually more insecure than Access' *DE files. Because they compile into bytecode, it's very easy to dissemble and obtain source code. That's why they distribute obfuscater.

C++ would be marginally better but there's also decompiler for machine code so it's not that hard to obtain the keys or other important details. *DE files, being relatively obscure and undocumented (in the sense we don't know anything about its symbols) is more likely to be far more difficult to reverse engineer.

If one really, really want a secure environment, a web application _may_ be the best bet since they have no direct control over the server but there's holes that needs to be plugged.

At the end of day, it has to be remembered that security can't be solved by technology all times. Sometime it's actually a human resources issue.

 

[SteveSchapel]

At the end of day, it has to be remembered that security can't be solved by technology all times. Sometime it's actually a human resources issue.

http://facets.datamanagementsolutions.biz/2009/02/access-security.html