MS Access: Is it possible to time bomb access

  • Thread starter Thread starter Gary Dikkema
  • Start date Start date
G

Gary Dikkema

I plan to release a product that will have a licensing duration of x days...

Short of code within the application ( which is possible to do), how can I
control use?

Is DRM an option?

Gary D
 
Gary Dikkema said:
I plan to release a product that will have a licensing duration of x days...

Short of code within the application ( which is possible to do), how can I
control use?
Click to expand...

In my view it is easier to limit the amount of rows allowed in some crucial
table(s) than to use Date/Time limitations. Then you don't have to worry
about people resetting the system clock or other nonsense.

In one of my apps the program performs a security check by sending an
HTTPRequest over the internet to a Java Servlet. That servlet compares
their authorization number to one stored in a database to see if they are
authorized to use the program. I actually use this to prevent the program
from being authorized more than once without having to call me for a reset,
but one could easily adapt such a system to enforce a time constraint.

Of course not all applications would lend themselves to a solution
requiring web access. I suspect that in the not too distant future though
this will become more and more common.
 
Interesting!

Could this process not be modified to disallow someone from viewing the
database content?

Just musing...

Thanks!

Gary D
 
Gary Dikkema said:
Interesting!

Could this process not be modified to disallow someone from viewing the
database content?

Just musing...
Click to expand...

As previously stated, as long as the data is stored in an Access/Jet table
you really cannot implement security beyond that built into the user-level
security that comes with Access and this is fairly easily broken by anyone
who knows how or is relatively motivated to find out how.
 
Not hard to believe at all. Access is a desktop database system. It was
never intended to be as secure as, say, SQL Server or Oracle. There are many
solutions available that offer far more secure data access and manipulation,
but they come with a price, both in terms of cash outlay and
development/learning time.
 
Many of the problems arise from simple crypto mistakes, not because it is a
desktop system.

For example, the fact that the passwords are reversible, arises from a
simple, schoolboy howler mistake that msoft made when they implemented the
DES encryption of the passwords in the workgroup file. With the proper
method, it would have made the passwords completely impossible to
reverse-engineer - not matter HOW much access you had to the workgroup file.

Of course, even if they had done that properly, you could just patch the
relevent codefiles to accept anything as a valid password. There is at least
one prduct around, that does this. So, IMO, it is >not< the accessibility of
the >data< (mdb/mdw) files that makes the security vulnerable. They could
have made hat security invulnerable, if they had done it properly. It is the
accessbility & patchability of the >code< files (eg. the Jet DLLs) that
makes a desktop product vulnerable.

Cheers,
TC
 
Back
Top