RWOP queries, security and .NET front ends

[Freeserve]

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 CurrentObjectType.
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.dll, 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.

[MGFoster]

Freeserve wrote:

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 CurrentObjectType.
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.dll, 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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Why not use SQL Server CE ("the compact database"). See this URL:

http://www.microsoft.com/sql/CE/default.asp

The .NET newsgroups are on Microsoft news servers:

microsoft.public.dotnet.languages.csharp
microsoft.public.dotnet.languages.vb (not sure)

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQIW90YechKqOuFEgEQLbWgCg9T1HUPU1yQPHAUn1qPaE6I 1CNAMAn1MW
oZRu2yzCTMazXFPUEQU4TXLn
=WDbC
-----END PGP SIGNATURE-----

[Alan Cossey]

"MGFoster" <[e-mail]> wrote in message
news:g5*****************@newsread1.news.pas.earthl ink.net...

Freeserve wrote:

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 CurrentObjectType. 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.dll, 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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Why not use SQL Server CE ("the compact database"). See this URL:

http://www.microsoft.com/sql/CE/default.asp

The .NET newsgroups are on Microsoft news servers:

microsoft.public.dotnet.languages.csharp
microsoft.public.dotnet.languages.vb (not sure)

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQIW90YechKqOuFEgEQLbWgCg9T1HUPU1yQPHAUn1qPaE6I 1CNAMAn1MW
oZRu2yzCTMazXFPUEQU4TXLn
=WDbC
-----END PGP SIGNATURE-----

Thanks for replying. As far as I am aware SQL Server CE only works on
devices running the .NET Compact Framework and, though my app will include
this and I may well use SQLSCE for that part, I want to use Jet/Access to
store data on the PC for various reasons, rather than use SQL Server / MSDE
2000.

Alan