Not sure whether this is the right group, but I can't find anything in the
..NET groups and my apologies if this has already been covered or is
considered "off subject".
I am looking at using an Access database to hold data which will be handled
via VB.NET and I am not sure about some of the security aspects. I am going
the .NET route as part of the application involves using a Pocket PC and I
don't want part to involve deploying msaccess.exe and so on as well as the
..NET stuff. Including a .mdb file in with the .NET stuff is OK.
With an Access front end it is possible to stop users from running RWOP
queries except when called from an Access form by putting a function in the
query which checks where it is being called from by using CurrentObjectTy pe.
I am looking for something similar to use with VB.NET. However, as far as I
can see, if the VB.NET app calls the RWOP query in the Access database,
there is not much you can do to stop them calling the RWOP query themselves,
e.g. from their own Access database. My question is: How to I stop users
from running queries or accessing tables in the Access back end while still
giving my VB.NET "front end" sufficient access, please?
When I've done Access apps that require reasonable security I've done things
like:
1) Use user-level security.
2) Develop using one MDW file, but not allow users to use this. Instead they
use the default system.mdw. Users, therefore, enter the app as the Admin
user from system.mdw and the app then checks their Windows ID to specify
which parts of the app they can access.
3) Do a proper removal of the Shift bypass stuff so they are forced into
running code that picks up their Windows ID. Either that or ID's are held in
tables and used from there, with the users having to enter an ID and
password to authenticate themselves.
The problem seems to be that if I am using user-level security for the
Access database, VB.NET requires a user ID and password for this that also
requires the existence of - and physical access to - an MDW file with those
details in. This is where the security hole appears to be. As many people
know, if a user has physical access to a .mdw file, there are tools around
that will let them see all groups, ID's and passwords in that .mdw file. I
also know that it is possible for some people to break into a .mdb file even
without the developer's .mdw file, but if people are that desperate to get
into my app, well, they need to get a life. The level of sensitivity of the
data is such that I need "only" to stop people running RWOP queries that
they shouldn't be running.
The best I can think of is to give the .mdw file a non-standard name, e.g.
MyPretendName.d ll, and try and hide it somewhere on the user's PC other than
in the application's own folder, in which case I then need to find a way of
deploying it there and I haven't got that far in my understanding of .NET
application deployment to be able to do that. It doesn't appear a very
robust way to do it either.
Any help would be much appreciated. I don't expect this is the first time
anyone has wanted to know the answer to this.
Alan Cossey
PS Using SQL Server or the like is not an option.
..NET groups and my apologies if this has already been covered or is
considered "off subject".
I am looking at using an Access database to hold data which will be handled
via VB.NET and I am not sure about some of the security aspects. I am going
the .NET route as part of the application involves using a Pocket PC and I
don't want part to involve deploying msaccess.exe and so on as well as the
..NET stuff. Including a .mdb file in with the .NET stuff is OK.
With an Access front end it is possible to stop users from running RWOP
queries except when called from an Access form by putting a function in the
query which checks where it is being called from by using CurrentObjectTy pe.
I am looking for something similar to use with VB.NET. However, as far as I
can see, if the VB.NET app calls the RWOP query in the Access database,
there is not much you can do to stop them calling the RWOP query themselves,
e.g. from their own Access database. My question is: How to I stop users
from running queries or accessing tables in the Access back end while still
giving my VB.NET "front end" sufficient access, please?
When I've done Access apps that require reasonable security I've done things
like:
1) Use user-level security.
2) Develop using one MDW file, but not allow users to use this. Instead they
use the default system.mdw. Users, therefore, enter the app as the Admin
user from system.mdw and the app then checks their Windows ID to specify
which parts of the app they can access.
3) Do a proper removal of the Shift bypass stuff so they are forced into
running code that picks up their Windows ID. Either that or ID's are held in
tables and used from there, with the users having to enter an ID and
password to authenticate themselves.
The problem seems to be that if I am using user-level security for the
Access database, VB.NET requires a user ID and password for this that also
requires the existence of - and physical access to - an MDW file with those
details in. This is where the security hole appears to be. As many people
know, if a user has physical access to a .mdw file, there are tools around
that will let them see all groups, ID's and passwords in that .mdw file. I
also know that it is possible for some people to break into a .mdb file even
without the developer's .mdw file, but if people are that desperate to get
into my app, well, they need to get a life. The level of sensitivity of the
data is such that I need "only" to stop people running RWOP queries that
they shouldn't be running.
The best I can think of is to give the .mdw file a non-standard name, e.g.
MyPretendName.d ll, and try and hide it somewhere on the user's PC other than
in the application's own folder, in which case I then need to find a way of
deploying it there and I haven't got that far in my understanding of .NET
application deployment to be able to do that. It doesn't appear a very
robust way to do it either.
Any help would be much appreciated. I don't expect this is the first time
anyone has wanted to know the answer to this.
Alan Cossey
PS Using SQL Server or the like is not an option.
Comment