Access security hole?

  • Thread starter Thread starter Neil W
  • Start date Start date
N

Neil W

Lets say I apply "password" to northwind.mdb. When I run MSAccess, I enter
"password" at the prompt and I am in.

Now another person starts a second instance of MSAccess. Since
Northwind.mdb is already opened in one instance of Access, they can connect
to northwind.mdb from the second instance without having to know or enter
the password!

Is there any way of preventing this?

Thanks.
 
Neil,

Not sure how you set up the security but that shouldn't happen. Have a look
at...

http://www.jmwild.com/

--
Gina Whipp
2010 Microsoft MVP (Access)

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

Lets say I apply "password" to northwind.mdb. When I run MSAccess, I enter
"password" at the prompt and I am in.

Now another person starts a second instance of MSAccess. Since
Northwind.mdb is already opened in one instance of Access, they can connect
to northwind.mdb from the second instance without having to know or enter
the password!

Is there any way of preventing this?

Thanks.
 
Thanks for the reply, but can you be more specific? Is there a specific
article or tip I should look at?
 
 
Stewart said:
I did not see any information on how to secure an Access 2007 accdb or
accde database.

Microsoft has chosen to remove workgroup security for accdb and accde
files. So you now have to roll your own.

Do you have any information on securing the current MS Access database
structure? In particular how do you secure the database against an
authorized user -- someone with read/write access to the folder the
database is in and who has the password -- from poking around in it?
Click to expand...

You can't. If you want security that applies to people allowed to open your
file then revert to MDB format or use a server database like SQL Server.
 
I did not see any information on how to secure an Access 2007 accdb or accde
database.

Microsoft has chosen to remove workgroup security for accdb and accde files.
So you now have to roll your own.

Do you have any information on securing the current MS Access database
structure? In particular how do you secure the database against an
authorized user -- someone with read/write access to the folder the database
is in and who has the password -- from poking around in it?
 
Thanks. Can RevokeActiveObject be used to stop another program from doing a
GetObject on that Access database?
 
Arvin Meyer said:
You can build an ACCDE, which keeps them from idly poking around the
objects, but not the data.
Click to expand...

Accde only protects code. All of the other objects are unprotected.
 
Accde only protects code. All of the other objects are
unprotected.
Click to expand...

In what sense do you mean "unprotected?"

You can't make changes to the design of code-bearing objects in an
ACCDE/MDE, which is what Arvin was referring to. It's true that the
properties/methods of those objects are still viewable, but they
have to be since otherwise, you wouldn't be able to do anything with
them at runtime.
 
Can RevokeActiveObject be used to stop another program from doing
a GetObject on that Access database?
Click to expand...

Without ULS, the only ways to prevent runtime access to the objects
internal to an Access front end are:

1. deny access via the file system.

2. password protect and encrypt the front end and don't give out the
password.

Neither of these is particularly satisfactory. But I have a hard
time understanding why you'd want to deny someone access to the
internal objects in an Access front end if that person has been
properly granted read access to the location of that Access front
end.

This is the old trust problem -- in order for people to get useful
work done, they have to have a certain level of permission to use
and edit data. If you can't trust them, you can't given them that
access. But that means they can't do their work, so you have to
decide how much risk you can tolerate, or how much trust you have in
your employees.

I do agree that Jet ULS *did* provide another layer of
control/access that was useful if not bulletproof, and it's a shame
that MS has removed it. I can understand why they consider it a
waste of time to protect data, but they've not provided anything to
protect front end objects, though that horse left the barn with
A2000 and the monolithic VBA project, where you didn't have security
on individual objects, just on the VBA project as a whole.
 
David W. Fenton said:
In what sense do you mean "unprotected?"

You can't make changes to the design of code-bearing objects in an
ACCDE/MDE, which is what Arvin was referring to. It's true that the
properties/methods of those objects are still viewable, but they
have to be since otherwise, you wouldn't be able to do anything with
them at runtime.
Click to expand...

You can replace macros, make changes to table content and definitions, make
changes to queries, make changes to properties, make changes to the ribbon,
etc.
 
Yes, this is a well known feature of Access.

It has been used as the only method of opening
a password-protected database as a com object,
(since Access has never supported com monikers).

However, as I said in the other thread, it is only
a "security hole" on your pc, while you are logged
in, and you have the database open, and you have
a specially crafted malicious application or malicious
user using your PC at the same time.

In that situation, an ordinary key-logger would also
be a problem, and would not have to be specially
crafted.

My conclusion is that if you are worried about the
security of your Access Application, you should
use a Screen Saver to lock your PC when you are
away from the desk.

(david)
 
The fact that Microsoft has chosen to do this shows that they still do not
take data security seriously.
 
Stewart Berman said:
You can replace macros, make changes to table content and definitions,
make
changes to queries, make changes to properties, make changes to the
ribbon,
etc.
Click to expand...

Professional developers rarely use macros. Ribbons are not database objects,
they are Access objects. You cannot change properties of non-data objects. I
already mentioned that you can change data. Tables and queries can be locked
out of view by hiding the Navigation pane and using a menu.

Access security has never been totally (100%) effective anyway. Using the
methods I've outline, you can keep your fellow workers out of mischief.
Really determined miscreants should be identified and fired, long before you
ever get to data loss stage. That becomes an HR issue.

Outsiders shouldn't be allowed into the network. That is an IT issue if they
are.

If you are looking for 100% security, hire a team of armed 250 pound men and
pay them very well.
 
You can replace macros, make changes to table content and
definitions, make changes to queries, make changes to properties,
make changes to the ribbon, etc.
Click to expand...

Tables don't belong in an MDE.

Which is, I think, where I came in on this discussion...
 
The fact that Microsoft has chosen to do this shows that they
still do not take data security seriously.
Click to expand...

I read it more as them not taking Access seriously.
 
Arvin Meyer said:
Professional developers rarely use macros. Ribbons are not database objects,
they are Access objects. You cannot change properties of non-data objects. I
already mentioned that you can change data. Tables and queries can be locked
out of view by hiding the Navigation pane and using a menu.

Access security has never been totally (100%) effective anyway. Using the
methods I've outline, you can keep your fellow workers out of mischief.
Really determined miscreants should be identified and fired, long before you
ever get to data loss stage. That becomes an HR issue.

Outsiders shouldn't be allowed into the network. That is an IT issue if they
are.

If you are looking for 100% security, hire a team of armed 250 pound men and
pay them very well.
Click to expand...

You can create/change the contents of the USysRibbons table and thus the
Ribbon. You can also change the database properties like enabling the use
of the shift key to bypass an AutoExec macro or a Startup form. You can
turn the Navigation pane back on as well as the built in menus. All it
requires is connecting to the instance of Access that has the target
database open from another instance of Access and then run a few lines of
VBA code and the target database is wide open.
 
Back
Top