Bulletproofing database with .mde file

[John S. Ford, MD]

I've made an Access 97 application which will be used by multiple users. I
set the start-up properties very restrictively so as not to allow the
database window to be visible, limited short-cuts menus, default menus, etc.
I then created an .mde file as well.

The problem is this: a user can click on my start icon and quickly hit the
shift key which will open the database WITH the database window. The user
doesn't have access to forms, design view, etc. but DOES have the ability to
delete tables and queries.

How can I get around this? is there a way to guarantee that the database
window can't be accessed without using a runtime distribution?

John

 

[Allen Browne]

Check out the AllowBypassKey property.

 

[John S. Ford, MD]

Allen,

I looked through the help files in Access 97 and that looks like exactly the
sort of think I'm looking for. I read the example of how to use it which
seems rather complicated. There was a sub called SetStartupProperties in
the example. I think I understand how it works. My question is, where do I
deploy such a function? With a particular form in the OnOpen event? I'm a
little confused.

John

 

[Tom Wickerath]

John,

If you go to Albert Kallal's web site, he has the required code in an Access database which you
can download and run against any other database.

http://www.attcanada.net/~kallal.msn/msaccess/msaccess.html

Of course, any user who happens to know about the AllowBypass property will be able to un-do this
setting with similar code. However, this should be enough to keep >99% of the users out.

For that last 1%, you could implement Access Security:
http://www.mvps.org/access/general/gen0040.htm

However, Access security (especially with Access 97) is not all that secure, so anyone with
malicious intent who is also a legitimate user of your database (ie. has the required folder
privileges) is probably going to be able to get in anyway.

Tom
___________________________________


Allen,

I looked through the help files in Access 97 and that looks like exactly the
sort of think I'm looking for. I read the example of how to use it which
seems rather complicated. There was a sub called SetStartupProperties in
the example. I think I understand how it works. My question is, where do I
deploy such a function? With a particular form in the OnOpen event? I'm a
little confused.

John

 

[Arvin Meyer]

However, Access security (especially with Access 97) is not all that secure, so anyone with
malicious intent who is also a legitimate user of your database (ie. has the required folder
privileges) is probably going to be able to get in anyway.

Other than password cracking utilities, which now can crack almost anything,
Access security will keep out most users. One trick to setting security on
an Access database is to split the database and give no permissions on the
tables. Use WITHOWNERACCESSOPTION queries for all user interaction. Doing
that ensures that the back-end remains closed to all but the owner, the
admin, and someone with the ability to crack the encrypted system.mdw. I
like to ship an altered system.mdw which doesn't even contain the admin
user.

One more thing. The AllowByPassKey can be somewhat protected against changes
by using the 4th argument. Have a look at Michael Kaplan's post on the
subject:

http://www.mvps.org/access/general/gen0040.htm
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[TC]

(snip)

Of course, any user who happens to know about the AllowBypass property will be able to un-do this
setting with similar code.

Not so.

If the property is created with the DDL parameter of the CreateProperty call
set to True, then, only a member of the Admins group >of the workgroup file
that was used to create the database< will be able to change the setting.

Members of the Admins group of >other< workgroup files, will not be able to
change the setting.

Normal users (in any workgroup file) will not be able to change the setting.

HTH,
TC

 

[Joan Wild]

Not so.

If the property is created with the DDL parameter of the
CreateProperty call set to True, then, only a member of the Admins
group >of the workgroup file that was used to create the database<
will be able to change the setting.

John made no indication that his database was secure, which means the
standard system.mdw was the workgroup used to create the database.

The DDL parameter is irrelevant in that case.

 

[TC]

John made no indication that his database was secure, which means the
standard system.mdw was the workgroup used to create the database.

The DDL parameter is irrelevant in that case.

Again, I would say "not so".

The Admins group of >his< default system.mdw, and the Admins group of >my<
default system.mdw, are only identical (ie. have the same SID), if his & my
PC had the same company & organization names at the time those workgroups
were created. And in general, they won't. So the two Admins groups are not
the same. A member of >his< default workgroup file's Admins group, is >not<
a member of the Admins group of the workgroup file which was used to create
my unsecured database.

TC

 

[Tom Wickerath]

To "TC":

I included the following in my note:
"However, Access security (especially with Access 97) is not all that secure, so anyone with
malicious intent who is also a legitimate user of your database (ie. has the required folder
privileges) is probably going to be able to get in anyway."

You answered with the following:
"Normal users (in any workgroup file) will not be able to change the setting."

Ummm....excuse me. Do you believe that someone with malicious intent who also might be a
legitimate user of a database is the same as a normal user? I certainly don't. The fact remains
that Access security simply raises the bar. I'm sure you don't need to be reminded that there are
password cracking utilities that can be used to gain entry to a secured Access database (any
version) even if the person attempting to do so does not have the associated .MDW file. I think
you are placing too much faith in Access security! And, as Joan Wild pointed out to you, the
good doctor made no mention that his database was even secured to begin with.

Question for you: Why don't you indicate your >real< name in your posts? Why the need to hide
behind a set of initials?

Tom

_______________________________________________________


Again, I would say "not so".

The Admins group of >his< default system.mdw, and the Admins group of >my<
default system.mdw, are only identical (ie. have the same SID), if his & my
PC had the same company & organization names at the time those workgroups
were created. And in general, they won't. So the two Admins groups are not
the same. A member of >his< default workgroup file's Admins group, is >not<
a member of the Admins group of the workgroup file which was used to create
my unsecured database.

TC
_______________________________________________________


TC wrote:

Not so.

If the property is created with the DDL parameter of the
CreateProperty call set to True, then, only a member of the Admins
group >of the workgroup file that was used to create the database<
will be able to change the setting.

John made no indication that his database was secure, which means the
standard system.mdw was the workgroup used to create the database.

The DDL parameter is irrelevant in that case.

 

['69 Camaro]

Hi, TC.

The entertainment value of your efforts to educate Joan Wild and Tom
Wickerath about Access security are surely worth the amount that I paid my
ISP this month to access these News Groups. I really hate to give hackers
clues about Access security, but there's so much information already
available, my pointing to some of it probably won't add that much value for
them, but it may help you to understand the statements that Joan and Tom,
both experts in their field, have made.

In your research on Access security, you may have missed some posts in the
following thread:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&th=491ef7b9c11678f0&rnum=9

Also, the Security FAQ, which I have no doubt that you are familiar with (as
you've advised others to download and read it), contains this sentence in
paragraph 1.1:

"Use the Workgroup Administrator program (Wrkgadm.exe) to create a new
workgroup information file."

This one single sentence is *so* important that ignoring it makes the use of
the DDL parameter in disabling the AllowBypassKey Property irrelevant, as
Joan pointed out to you. This one single sentence is *so* important that
ignoring it makes your statement regarding the issue that the Admins group
in >your< default System.MDW file is different than the Admins group in

his< default System.MDW file moot, also.

When the light bulb comes on, PLEASE DO NOT POST the revelation in the News
Groups, since hackers have enough clues without us spelling it out for them.

Thank you.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

 

[test]

To "TC":

I included the following in my note:
"However, Access security (especially with Access 97) is not all that secure, so anyone with
malicious intent who is also a legitimate user of your database (ie. has the required folder
privileges) is probably going to be able to get in anyway."

You answered with the following:
"Normal users (in any workgroup file) will not be able to change the setting."

Ummm....excuse me. Do you believe that someone with malicious intent who also might be a
legitimate user of a database is the same as a normal user? I certainly don't. The fact remains
that Access security simply raises the bar. I'm sure you don't need to be reminded that there are
password cracking utilities that can be used to gain entry to a secured Access database (any
version) even if the person attempting to do so does not have the associated .MDW file. I think
you are placing too much faith in Access security!

Huh? I am discussing the facts of a technical issue pertaining to the
AllowBypassKey property, the DDL parameter of the CreateProperty method, and
default system workgroup files. Nothing above is relevant to that
discussion.

And, as Joan Wild pointed out to you, the good doctor made no mention that his
database was even secured to begin with.

And, as I explicitly said in my post, that is irrelevant to the point that I
made. Did you actually read what I wrote? I'm sure that Joan will reply, in
due course, until we reach agreement on the facts of the matter, whatever
they turn out to be.

Question for you: Why don't you indicate your >real< name in your posts? Why the need to hide
behind a set of initials?

Sigh. I went through this some years ago. I choose not to reveal my personal
details, to every person who reads my posts. This hasn't stopped me
communicating by name (by email) with various people, including other
posters, & microsoft employees, from time to time, when needs arose.

I have answered nearly 6,000 questions in various Access newsgroups over the
years. That doesn't sound like "hiding", to me.

It is my right (not yours) to decide what personal information I reveal, and
I will exercise that right as I see fit.

TC

 

[TC]

Hi, TC.

The entertainment value of your efforts to educate Joan Wild and Tom
Wickerath about Access security are surely worth the amount that I paid my
ISP this month to access these News Groups.

Hi Gunny. I'm sure not trying to "educate" Joan! She's an aknowledged
expert on Access security. But I know a good deal about it, myself. In this
case, I disagree with what she has said. But I may be wrong, & she will
doubtless continue to argue her case, in due course.

I really hate to give hackers
clues about Access security, but there's so much information already
available, my pointing to some of it probably won't add that much value for
them, but it may help you to understand the statements that Joan and Tom,
both experts in their field, have made.

In your research on Access security, you may have missed some posts in the
following thread:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&th=491ef7b9c1167
8f0&rnum=9

Thanks for the reference. I'll review that thread in due course. But I can
do whatever I want to, already, with my own unlocking tools.

Also, the Security FAQ, which I have no doubt that you are familiar with (as
you've advised others to download and read it), contains this sentence in
paragraph 1.1:

"Use the Workgroup Administrator program (Wrkgadm.exe) to create a new
workgroup information file."

This one single sentence is *so* important that ignoring it makes the use of
the DDL parameter in disabling the AllowBypassKey Property irrelevant, as
Joan pointed out to you. This one single sentence is *so* important that
ignoring it makes your statement regarding the issue that the Admins group
in >your< default System.MDW file is different than the Admins group in

Yes, that sentence *is* important. But I'm not convinced that it invalidates
what I said to Joan.

 

[Tom Wickerath]

TC:

I agree that it's your right to decide what information to reveal. I have a much greater
respect, in general, for those who are willing to put their name behind their advice.

Tell you what, why don't we take this discussion off-line. I invite you to send me an e-mail,
with a valid return address, since I obviously cannot reply to "(e-mail address removed)".

Tom
_____________________________________

To "TC":

I included the following in my note:
"However, Access security (especially with Access 97) is not all that secure, so anyone with
malicious intent who is also a legitimate user of your database (ie. has the required folder
privileges) is probably going to be able to get in anyway."

You answered with the following:
"Normal users (in any workgroup file) will not be able to change the setting."

Ummm....excuse me. Do you believe that someone with malicious intent who also might be a
legitimate user of a database is the same as a normal user? I certainly don't. The fact remains
that Access security simply raises the bar. I'm sure you don't need to be reminded that there are
password cracking utilities that can be used to gain entry to a secured Access database (any
version) even if the person attempting to do so does not have the associated .MDW file. I think
you are placing too much faith in Access security!

Huh? I am discussing the facts of a technical issue pertaining to the
AllowBypassKey property, the DDL parameter of the CreateProperty method, and
default system workgroup files. Nothing above is relevant to that
discussion.

And, as Joan Wild pointed out to you, the good doctor made no mention that his
database was even secured to begin with.

And, as I explicitly said in my post, that is irrelevant to the point that I
made. Did you actually read what I wrote? I'm sure that Joan will reply, in
due course, until we reach agreement on the facts of the matter, whatever
they turn out to be.

Question for you: Why don't you indicate your >real< name in your posts? Why the need to hide
behind a set of initials?

Sigh. I went through this some years ago. I choose not to reveal my personal
details, to every person who reads my posts. This hasn't stopped me
communicating by name (by email) with various people, including other
posters, & microsoft employees, from time to time, when needs arose.

I have answered nearly 6,000 questions in various Access newsgroups over the
years. That doesn't sound like "hiding", to me.

It is my right (not yours) to decide what personal information I reveal, and
I will exercise that right as I see fit.

TC

 

[TC]

Aha!

On rereading your post, I now understand your tone.

You see >me< as the "hacker", and think that it is ludicrous for me to try
to "educate" Joan & Tom - "experts in their field".

Before you make a fool of yourself, perhaps you'd better read my other posts
in this & other newsgroups regarding Access security.

FYI, I broke the method years ago. I can desecure a fully secured &
encrypted mdb, without any workgroup file, using my own (home grown) tools.
But this does not prevent me arguing about technical issues (pertaining to
security), when I feel that I have something to say.

Ok?

TC

 

['69 Camaro]

Hi, TC.

To be honest, anyone with a deep understanding of Access security *is* a
hacker. That's how the majority of us got that deep understanding. The
word "hacker" has a connotation of maliciousness, but not all "hackers" are
malicious. For some, it's a very necessary skill.

At my company, we specialize in database disaster recovery and database
application "fix-its." In our business, having a deep understanding of
Access security allows us to quickly unlock valuable data for clients that
have lost the ability to access that data, and this knowledge also enables
us to advise our clients on how to effectively secure that data.

Clients may not know the user ID's or passwords, or even where the
appropriate files are stored on their servers. We've had to come up with
solutions anyway, because our clients expect us to be the experts. We've
experimented with the security and built tools to automate the recovery
processes. Anyone who has done this same experimentation and built similar
tools will know the vulnerabilities and how to overcome them to get at the
data, as well as how to prevent malicious hackers from taking advantage of
these vulnerabililities.

Joan Wild knows these vulnerabilities and the consequences of not taking
these vulnerabilities into account. So does Tom Wickerath. Anyone else who
read Joan's statement about the DDL parameter in disabling the
AllowBypassKey Property and knows these vulnerabilities understands
precisely why she made this statement.

You have the tools. Go experiment, and you'll find out why Joan made the
statement -- as well as the additional statements she's about to make after
she reads your posts. Just don't advertise the results of your experiments
to the malicious hackers reading the News Groups, please. I'd rather not
give them more clues than are already available.

Aha! On rereading your post, I now understand your tone.

My tone is one of amusement after reading your post to Joan, nothing more.
I'm not accusatory, if that's what you're thinking. I'm just a guide to
help you take another step in the learning process.

Before you make a fool of yourself

Oh, stop! I don't need anyone holding me back. I've had quite a bit of
practice, and I'm quite good at it, as my family and friends will quickly
attest to.

perhaps you'd better read my other posts
in this & other newsgroups regarding Access security.

I have. That's how I know you've advised others to download and read the
SecFAQ. You wouldn't have advised others to do something that you,
yourself, haven't already done. Access security has come up in discussions
before, and you've been a knowledgeable participant.

But this does not prevent me arguing about technical issues (pertaining to
security), when I feel that I have something to say.

Not only do you have the freedom of speech, you have the freedom to teach
others what you have learned. I'm merely asking you to use some amount of
restraint when a new revelation strikes you, because you are about to find
out something you didn't know. Congratulations. Not all of us are lucky
enough to make new discoveries about something we are passionate about, as
you obviously are about Access.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

 

[Joan Wild]

Joan Wild knows these vulnerabilities

You have no basis for that statement.

Just don't advertise the results of
your experiments to the malicious hackers reading the News Groups,
please. I'd rather not give them more clues than are already
available.

A simple search at Google will get anyone what they need. I doubt TC could
reveal anything that isn't already out there.

Anyone that uses Access security, and thinks it is 'secure', is really
fooling themselves. It really is a misnomer - but I still use it.

My clients are really not interested in hacking into their databases. They
just want to do their job - open the application and it presents to them
what they need. Jill in the orders department doesn't really need/want to
see all those forms/reports that the folks in the plant use, and vice-versa.
So when Jill logs in, she sees just what she needs.

Anyone that requires true security shouldn't be using Access, but rather a
server database like SQL Server.


Further up the thread TC wrote in response..

You are mistaken, TC. Every system.mdw is the same (including the Admins
group).

Nothing like a demo to show you. I have disabled the shift key using my
system.mdw on the file below. According to you, you won't be able to enable
it again using your system.mdw. You'll see that you can.
Test DDL Prop link at
http://wild.canadianwebs.com

 

[TC]

You have no basis for that statement.



A simple search at Google will get anyone what they need. I doubt TC could
reveal anything that isn't already out there.

Er, the DES key that encrypts the SIDs? That has not been published
anywhere, afaik. You'd also be lucky to find the RC4 base keys & key
schedule algorythm by a "simple search". Of course, the >products<
that are based on this information are readily available.

Anyone that uses Access security, and thinks it is 'secure', is really
fooling themselves. It really is a misnomer - but I still use it.

My clients are really not interested in hacking into their databases. They
just want to do their job - open the application and it presents to them
what they need. Jill in the orders department doesn't really need/want to
see all those forms/reports that the folks in the plant use, and vice-versa.
So when Jill logs in, she sees just what she needs.

Anyone that requires true security shouldn't be using Access, but rather a
server database like SQL Server.


Further up the thread TC wrote in response..


You are mistaken, TC. Every system.mdw is the same (including the Admins
group).

I'm happy to be corrected on this. I >assumed< that the default
workgroup file was created when Jet or Access was first run. If that
was the case, the Admins groups of different default workgroup files
would not always have the same SID.

Nothing like a demo to show you. I have disabled the shift key using my
system.mdw on the file below. According to you, you won't be able to enable
it again using your system.mdw. You'll see that you can.
Test DDL Prop link at
http://wild.canadianwebs.com

That would be a definitive test. But the link gave me:

"Forbidden
Remote Host: [10.11.96.102]
You do not have permission to access
http://wild.canadianwebs.com/testDDL.zip
Data files must be stored on the same site they are linked from.
Thank you for using canadianwebs.com"

As an alternative, I'm collecting the default workgroup files from
several PCs that I know have different company/organization names.
I'll check the SIDs of their Admins groups. If the SIDs are different,
I'm da man! If they're identical, you de gal!

Will post back here when I have the result.

Cheers,
TC

 

[TC]

You persist in suggesting that I do not understand what Joan is
talking about.

I understand exactly what she is talking about.

The nub of the issue under discussion, is whether all default
workgroup files do or do not have the same SID for the Admins group.

I suggest that you contribute your opinion on that, or improve the
information content of this thread by keeping out of it.

TC

 

[TC]

TC:

I agree that it's your right to decide what information to reveal. I have a much greater
respect, in general, for those who are willing to put their name behind their advice.

I've never understood that position. A poster's worth should be judged
by the accuracy & usefulness of what they post. As long as I use a
consistent nickname, who cares whether it's TC, or Fred Smith? And how
would anyone know that "Fred Smith" was accurate, anyway?

Tell you what, why don't we take this discussion off-line. I invite you to send me an e-mail,
with a valid return address, since I obviously cannot reply to "(e-mail address removed)".

I can't see where that discussion would lead us. But I'll email you
after sending this post.

Cheers,
TC

 

[Tom Wickerath]

TC:
I was able to download Joan's demo, and I had no problem at all changing the AllowBypassKey
setting.

So, in this case, she's de gal, but I'm afraid that you are not da man.....


Tom
_____________________________________________

Nothing like a demo to show you. I have disabled the shift key using my
system.mdw on the file below. According to you, you won't be able to enable
it again using your system.mdw. You'll see that you can.
Test DDL Prop link at
http://wild.canadianwebs.com

That would be a definitive test. But the link gave me:

"Forbidden
Remote Host: [10.11.96.102]
You do not have permission to access
http://wild.canadianwebs.com/testDDL.zip
Data files must be stored on the same site they are linked from.
Thank you for using canadianwebs.com"

As an alternative, I'm collecting the default workgroup files from
several PCs that I know have different company/organization names.
I'll check the SIDs of their Admins groups. If the SIDs are different,
I'm da man! If they're identical, you de gal!

Will post back here when I have the result.

Cheers,
TC