Bulletproofing database with .mde file

[Tom Wickerath]

TC:

Don't know what to say, but tonight I am getting the same error message that you mentioned when
attempting to download Joan's sample. I downloaded it without any problem this morning.

Tom
__________________________________


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

 

['69 Camaro]

Hi, Joan.

You have no basis for that statement.

When you made your statement about the DDL parameter being irrelevant in an
unsecured database, you obviously were not copying that statement from a
"help desk script." You made that statement based upon your own experience,
because you've observed the security vulnerabilities and know under
precisely what circumstances in which that DDL parameter will have no
impact. Those are the security vulnerabilities I was referring to. You
prove this knowledge of the security vulnerabilities every day. Most of us
don't have this knowledge -- unless we've been bitten by many of the
security vulnerabilities, ourselves.

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

Much of the information is available on the Internet, but it's
time-consuming to gather it. It's like searching for a few needles in a few
dozen haystacks. Google will point to the haystacks, but one must rummage
through the hay to find the needles. I see no reason for us to hand over
these needles on a magnet to malicious hackers.

Anyone that uses Access security, and thinks it is 'secure', is really
fooling themselves.

I agree 100%.

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

I agree, and I would add Oracle to the list, too. Others may add even more
RDBMS's.

My regards.

Gunny

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

(Any human can read my reply E-mail address and should alter it so that
a message will be forwarded to me. Spammers who use my UNALTERED
reply E-mail address will only satisfy the SpamEater's hunger.)

 

['69 Camaro]

Hi, TC.

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

I understand exactly what she is talking about.

Of course you understand what she's talking about. You merely disagreed
with Joan and gave your argument for why you disagreed with her. That's
what a debate is: a discussion with opposing viewpoints.

My point is that you didn't understand *why* she made the statement about
the DDL parameter being irrelevant in an unsecured database. But after your
experiments with using this parameter for the AllowBypassKey database
Property in an unsecured database, you will understand why. And that, of
course, was the goal: understanding that the default workgroup information
file is too universal to be effective for applying the DDL parameter when
creating the AllowBypassKey database Property, but also understanding that
this is only an effect. The cause is due to the default workgroup
information file being too universal to be effective for making vital
changes to the Admins group. Ignoring this universality is a fatal flaw
when attempting to implement user-level security.

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.

Ma'am, I have no idea what I have written that would provoke you to offer me
such a rude invitation to join this discussion. Nonetheless, I thank you
for the invitation, ma'am, and will join in the hopes that I may impune
myself of this transgression by offering further opportunities to learn more
about Access.

My regards.

Gunny

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

(Any human can read my reply E-mail address and should alter it so that
a message will be forwarded to me. Spammers who use my UNALTERED
reply E-mail address will only satisfy the SpamEater's hunger.)


"TC" wrote in message

 

[TC]

I'll accept that as soon as I can dl the file, change the prop myself,
*and* confirm that the DDL bit of the prop was set

Cheers,
TC

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

 

[TC]

Hi, TC.


Of course you understand what she's talking about. You merely disagreed
with Joan and gave your argument for why you disagreed with her. That's
what a debate is: a discussion with opposing viewpoints.

I'm glad you've come around to that opion.

My point is that you didn't understand *why* she made the statement about
the DDL parameter being irrelevant in an unsecured database.

I believe that I do understand why she said it.

She says that a member of the Admins group of *any* default wgf, can
change the DDL props of databases created against a *different*
default wgf.

This is effectively saying, IMO, that all default workgroup files have
the same SID for their Admins group (unless I am missing something).

I believed, as an educated opinion (without having actually tested it
:-(, that all default workgroup files do >not< always have the same
SID for their Admins groups.

I concluded, from that, that a member of an arbitrary default wgf
could >not< necessarily change the DDL props of a database created
against a different default wgf.

It seems that she is probably right. But I have not been able to
confirm that myself, yet, because I've been unable to dl her file, &
I've been busy for the past few days.

I still plan to confirm it myself - which I can do without her file -
and I will post back here as soon as I've done so.

But after your
experiments with using this parameter for the AllowBypassKey database
Property in an unsecured database, you will understand why. And that, of
course, was the goal: understanding that the default workgroup information
file is too universal to be effective for applying the DDL parameter when
creating the AllowBypassKey database Property, but also understanding that
this is only an effect. The cause is due to the default workgroup
information file being too universal to be effective for making vital
changes to the Admins group. Ignoring this universality is a fatal flaw
when attempting to implement user-level security.

I say it is >you< who are missing the point!

The key thing about a workgroup file, is the SID of the Admins group.
Anyone who can create a new workgroup file with the same SID for the
Admins group, has full access to your database.

The SID of the Admins group is based on the company & organization
names (or whetever they're called) on the PC, & the value of the
Workgroup Identifier (WID).

Since the default workgroup file has a >blank< WID, anyone who can
determine the default company & organization name on your PC, can
recreate that workgroup file, and gain full access to all database
that were created from the original file.

*That* is the reason for creating a new workgroup file with unique
(unpredictable) company/organization names and WID.

And that is really nothing to do with the question of, whether all
default workgroup files do or do not have the same SIDs for their
Admins groups.

Ma'am, I have no idea what I have written that would provoke you to offer me
such a rude invitation to join this discussion. Nonetheless, I thank you
for the invitation, ma'am, and will join in the hopes that I may impune
myself of this transgression by offering further opportunities to learn more
about Access.

Whatever that means!

HTH,
TC

 

[TC]

Tom, I emailed you (per your request), but have not had any reply.

If you did not get it, post back here & I will send again.

TC

 

[TC]

I still can not download it.

TC

TC:

Don't know what to say, but tonight I am getting the same error message that you mentioned when
attempting to download Joan's sample. I downloaded it without any problem this morning.

Tom
__________________________________


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