Security - more complex than I thought

[Mike MacSween]

S**t for brains strikes again!

Why did I do that? When I met the clients and at some point they vaguely
asked whether eventually would it be possible to have some people who could
read the data and some who couldn't but that it wasn't important right now.
And I said, 'sure, we can do that later'.

So now I've developed an app without any thought to security and am trying
to apply it afterwards. Doh!, doh! and triple doh!

I've experimented a lot recently with NT permissions. And thought I had it
all sussed. Which I think I almost have, NT wise, except that if I actually
want (basically) 2 NT groups, readonly and readwrite, I find now that there
are tons of stuff in even the readonly group where they will still need
write permissions on the back end. The error log table being one (so that'll
have to go out to a separate file). Update queries that run on the Open or
Current event of forms. And so on. Add new forms which open completely blank
(because the user hasn't got permission to append?) so hiding any of my
navigation buttons. etc. etc.

As a quick and dirty approach...

I though I'd set up users and groups, but mainly to give me something to
grab hold of. Then in the OnOpen of most forms check which group the user is
a member and make the form allowedits false and so on. That approach would
actually give me a finer level of granularity, as I could also disable
certain controls on the forms/switchboard etc. All this as an alternative to
using all the user/group permissions.

What approaches does anybody else use?

Apart from planning security from the beginning, properly, of course.

TIA, Mike MacSween (feeling like a chump)

[Michael \(michka\) Kaplan [MS]]

Re: Security - more complex than I thought

You have unforturnately made a promise that you cannot effectively keep --
AT ALL. The best thing you can do is point to the industry-known limitations
of Jet/Access (acknowledged by many large organizations like HIPPA, the
banking industry, and others) and blame them for the fact that this will not
work.


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message
news:3faf65d3$0 $52886$5a6aecb4 @news.aaisp.net .uk...[color=blue]
> S**t for brains strikes again!
>
> Why did I do that? When I met the clients and at some point they vaguely
> asked whether eventually would it be possible to have some people who[/color]
could[color=blue]
> read the data and some who couldn't but that it wasn't important right[/color]
now.[color=blue]
> And I said, 'sure, we can do that later'.
>
> So now I've developed an app without any thought to security and am trying
> to apply it afterwards. Doh!, doh! and triple doh!
>
> I've experimented a lot recently with NT permissions. And thought I had it
> all sussed. Which I think I almost have, NT wise, except that if I[/color]
actually[color=blue]
> want (basically) 2 NT groups, readonly and readwrite, I find now that[/color]
there[color=blue]
> are tons of stuff in even the readonly group where they will still need
> write permissions on the back end. The error log table being one (so[/color]
that'll[color=blue]
> have to go out to a separate file). Update queries that run on the Open or
> Current event of forms. And so on. Add new forms which open completely[/color]
blank[color=blue]
> (because the user hasn't got permission to append?) so hiding any of my
> navigation buttons. etc. etc.
>
> As a quick and dirty approach...
>
> I though I'd set up users and groups, but mainly to give me something to
> grab hold of. Then in the OnOpen of most forms check which group the user[/color]
is[color=blue]
> a member and make the form allowedits false and so on. That approach would
> actually give me a finer level of granularity, as I could also disable
> certain controls on the forms/switchboard etc. All this as an alternative[/color]
to[color=blue]
> using all the user/group permissions.
>
> What approaches does anybody else use?
>
> Apart from planning security from the beginning, properly, of course.
>
> TIA, Mike MacSween (feeling like a chump)
>
>[/color]

[bzamfir]

Re: Security - more complex than I thought

Hi,

If the "real" security isn't a concern (I mean some real crackers who might
want to break your BE database), and you just want to provide some security
for regular users, you can try the following:

1. Make you BE password-protected
2. Link it to front-end app
3. In front-end app, you can get rid of Access build-in security and
implement your own security model : groups, users and restrictions
4. Make your application MDE and also set appropriatre properties to skip
Shift at startup.

This will prevent regular users to break into your data.

But, as I told, this is not for guys who "really" want to get into your
data.

I didn't looked for, but I heard there are tools on internet who can break
Access database password, and also decompilers for MDE, so...

Few thoughts about implementation:

Users belongs to groups

Restrictions can be defined by this:
Restriction name (like "Disable view of Customerts form", or "Disable
Printing of X report", or "Hiding Z information" or whatsever)
For each restricton you can create some logic (it should be data-driven, to
be easily extended by adding new restrictions, as they are required) which
will disable / hide the required controls / forms / menu entries / reports /
whatsever.

Then, in OpenEvent of every for and report, you should call a function which
will check appropriate permissions for logged user, and act as appropriate
(either prevent form for loading or hiding / disabling controls on it).

As an example, suppose you have a form called Employees, with a tab control
with two pages (one for personal data and one for employment data), anf you
want a group to not be able to view PersonalData tab

I have developed such module once, so if you are interested in this, please
contact me.

Regards,
Bogdan



----- Original Message -----
From: "Mike MacSween" <mike.macsween. nospam@btintern et.com>
Newsgroups: comp.databases. ms-access
Sent: Monday, November 10, 2003 10:16 AM
Subject: Security - more complex than I thought

[color=blue]
> S**t for brains strikes again!
>
> Why did I do that? When I met the clients and at some point they vaguely
> asked whether eventually would it be possible to have some people who[/color]
could[color=blue]
> read the data and some who couldn't but that it wasn't important right[/color]
now.[color=blue]
> And I said, 'sure, we can do that later'.
>
> So now I've developed an app without any thought to security and am trying
> to apply it afterwards. Doh!, doh! and triple doh!
>
> I've experimented a lot recently with NT permissions. And thought I had it
> all sussed. Which I think I almost have, NT wise, except that if I[/color]
actually[color=blue]
> want (basically) 2 NT groups, readonly and readwrite, I find now that[/color]
there[color=blue]
> are tons of stuff in even the readonly group where they will still need
> write permissions on the back end. The error log table being one (so[/color]
that'll[color=blue]
> have to go out to a separate file). Update queries that run on the Open or
> Current event of forms. And so on. Add new forms which open completely[/color]
blank[color=blue]
> (because the user hasn't got permission to append?) so hiding any of my
> navigation buttons. etc. etc.
>
> As a quick and dirty approach...
>
> I though I'd set up users and groups, but mainly to give me something to
> grab hold of. Then in the OnOpen of most forms check which group the user[/color]
is[color=blue]
> a member and make the form allowedits false and so on. That approach would
> actually give me a finer level of granularity, as I could also disable
> certain controls on the forms/switchboard etc. All this as an alternative[/color]
to[color=blue]
> using all the user/group permissions.
>
> What approaches does anybody else use?
>
> Apart from planning security from the beginning, properly, of course.
>
> TIA, Mike MacSween (feeling like a chump)
>
>[/color]

"Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message
news:3faf65d3$0 $52886$5a6aecb4 @news.aaisp.net .uk...[color=blue]
> S**t for brains strikes again!
>
> Why did I do that? When I met the clients and at some point they vaguely
> asked whether eventually would it be possible to have some people who[/color]
could[color=blue]
> read the data and some who couldn't but that it wasn't important right[/color]
now.[color=blue]
> And I said, 'sure, we can do that later'.
>
> So now I've developed an app without any thought to security and am trying
> to apply it afterwards. Doh!, doh! and triple doh!
>
> I've experimented a lot recently with NT permissions. And thought I had it
> all sussed. Which I think I almost have, NT wise, except that if I[/color]
actually[color=blue]
> want (basically) 2 NT groups, readonly and readwrite, I find now that[/color]
there[color=blue]
> are tons of stuff in even the readonly group where they will still need
> write permissions on the back end. The error log table being one (so[/color]
that'll[color=blue]
> have to go out to a separate file). Update queries that run on the Open or
> Current event of forms. And so on. Add new forms which open completely[/color]
blank[color=blue]
> (because the user hasn't got permission to append?) so hiding any of my
> navigation buttons. etc. etc.
>
> As a quick and dirty approach...
>
> I though I'd set up users and groups, but mainly to give me something to
> grab hold of. Then in the OnOpen of most forms check which group the user[/color]
is[color=blue]
> a member and make the form allowedits false and so on. That approach would
> actually give me a finer level of granularity, as I could also disable
> certain controls on the forms/switchboard etc. All this as an alternative[/color]
to[color=blue]
> using all the user/group permissions.
>
> What approaches does anybody else use?
>
> Apart from planning security from the beginning, properly, of course.
>
> TIA, Mike MacSween (feeling like a chump)
>
>[/color]

[Mike MacSween]

Re: Security - more complex than I thought

"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
message news:3fafa955$1 @news.microsoft .com...[color=blue]
> You have unforturnately made a promise that you cannot effectively keep --
> AT ALL. The best thing you can do is point to the industry-known[/color]
limitations[color=blue]
> of Jet/Access (acknowledged by many large organizations like HIPPA, the
> banking industry, and others) and blame them for the fact that this will[/color]
not[color=blue]
> work.[/color]

Sure, Access isn't 100% secure. That doesn't worry me. Where I f****d up was
not planning security from the start. I think that Access security can
probably be made a lot harder than people imagine. As I've posted a couple
of times but only one person has responded. By combining it with NT
permissions.

What approach do you use to Access security? The built in model or do you
'roll your own'

Cheers, Mike MacSween

[TC]

Re: Security - more complex than I thought


"Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message
news:3fb023a7$0 $52880$5a6aecb4 @news.aaisp.net .uk...[color=blue]
> "Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
> message news:3fafa955$1 @news.microsoft .com...[color=green]
> > You have unforturnately made a promise that you cannot effectively[/color][/color]
keep --[color=blue][color=green]
> > AT ALL. The best thing you can do is point to the industry-known[/color]
> limitations[color=green]
> > of Jet/Access (acknowledged by many large organizations like HIPPA, the
> > banking industry, and others) and blame them for the fact that this will[/color]
> not[color=green]
> > work.[/color]
>
> Sure, Access isn't 100% secure. That doesn't worry me. Where I f****d up[/color]
was[color=blue]
> not planning security from the start. I think that Access security can
> probably be made a lot harder than people imagine. As I've posted a couple
> of times but only one person has responded. By combining it with NT
> permissions.
>
> What approach do you use to Access security? The built in model or do you
> 'roll your own'[/color]


I don't understand your problem. If you want "some people who could read the
data and some people who couldn't", you can achieve this easily using Access
user-level security.

Of course, that is not un-hacakable, but neither is >>anything else<< that
is running on a PC that is open to codefile-level hacking.

Access security does not integrate directly with NT security, but you can
get the username carried across, so all the user has to do is to re-enter
his Access user-level password; which could be made the same as his NT
password.

So really, what is the poblem?

TC

[paii, Ron]

Re: Security - more complex than I thought

Put your restricted tables in a separate BE, then you can use NT security to
restrict access to that MDB. Your application would now have to link to more
then one BE and you will need to handle relationships between the BEs with
code. I have a BE file that contains employee information, It is store in a
directory that is not even visible to users that don't need this
information. Access has no problem with this, as long as your application
does not open the tables.

As for Form and Report access, I use a menu table that list the menu
description, Form/Report name and access levels allowed to use the menu
item. The application gets the user ID from the network login to determine
access level. The menu is access with list or combo box controls, filtered
to the menu items allowed by the access level. Now this is very hackable but
works very well in a controlled environment. You should be able to add such
a menu to your application with minimum modification to your code.


"Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message
news:3faf65d3$0 $52886$5a6aecb4 @news.aaisp.net .uk...[color=blue]
> S**t for brains strikes again!
>
> Why did I do that? When I met the clients and at some point they vaguely
> asked whether eventually would it be possible to have some people who[/color]
could[color=blue]
> read the data and some who couldn't but that it wasn't important right[/color]
now.[color=blue]
> And I said, 'sure, we can do that later'.
>
> So now I've developed an app without any thought to security and am trying
> to apply it afterwards. Doh!, doh! and triple doh!
>
> I've experimented a lot recently with NT permissions. And thought I had it
> all sussed. Which I think I almost have, NT wise, except that if I[/color]
actually[color=blue]
> want (basically) 2 NT groups, readonly and readwrite, I find now that[/color]
there[color=blue]
> are tons of stuff in even the readonly group where they will still need
> write permissions on the back end. The error log table being one (so[/color]
that'll[color=blue]
> have to go out to a separate file). Update queries that run on the Open or
> Current event of forms. And so on. Add new forms which open completely[/color]
blank[color=blue]
> (because the user hasn't got permission to append?) so hiding any of my
> navigation buttons. etc. etc.
>
> As a quick and dirty approach...
>
> I though I'd set up users and groups, but mainly to give me something to
> grab hold of. Then in the OnOpen of most forms check which group the user[/color]
is[color=blue]
> a member and make the form allowedits false and so on. That approach would
> actually give me a finer level of granularity, as I could also disable
> certain controls on the forms/switchboard etc. All this as an alternative[/color]
to[color=blue]
> using all the user/group permissions.
>
> What approaches does anybody else use?
>
> Apart from planning security from the beginning, properly, of course.
>
> TIA, Mike MacSween (feeling like a chump)
>
>[/color]

[Peter Miller]

Re: Security - more complex than I thought

On Mon, 10 Nov 2003 21:46:13 -0000, "Mike MacSween"
<mike.macsween. nospam@btintern et.com> wrote in
comp.databases. ms-access:
[color=blue]
>Sure, Access isn't 100% secure. That doesn't worry me. Where I f****d up was
>not planning security from the start. I think that Access security can
>probably be made a lot harder than people imagine. As I've posted a couple
>of times but only one person has responded. By combining it with NT
>permissions.[/color]

As you've no doubt found out, NT permissions are not enough to fill
the gaps in Access security. Access is not a service-based system, so
you will always need to expose the file space on the server used by
the db to each and every user who need the file. This statement can
be tempered somewhat by various methods (adp's, nt security only, etc)
but is basically true. While you can tighten NT security to a point,
you really can't get past the fact that as a file-server based rdbms,
Access w/jet will always be susceptible to easy hacking.

The reason for a lack of responses is not because nobody is interested
in better security for Access, but rather because many of us have
looked into this problem in some depth, and concluded, unfortunately,
that there is no good solution. This is not just to say that 100%
effectiveness is unachievable, but rather, that it is impossible to
secure *any* Access database beyond the point where it can be
desecured within seconds and a handful of lines of code, or within
minutes if done manually. You simply need a server-based rdbms if you
wish to deliver any remote level of meaningful security to your
client's databases.
[color=blue]
>What approach do you use to Access security? The built in model or do you
>'roll your own'[/color]

Both are fatally flawed and trivial to de-secure.

Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Mike MacSween]

Re: Security - more complex than I thought

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:ee32rvk5qg 9e65mr28l6dqtp3 htdh1d4i5@4ax.c om...[color=blue]
> On Mon, 10 Nov 2003 21:46:13 -0000, "Mike MacSween"
> <mike.macsween. nospam@btintern et.com> wrote in
> comp.databases. ms-access:[/color]

Thanks for you reply Peter
[color=blue]
> As you've no doubt found out, NT permissions are not enough to fill
> the gaps in Access security.[/color]

Actually I haven't found that yet, but no doubt I will. I'm trying various
ways of using NT permissions to stop people getting at the back end tables.
Mostly successfully. But I'll keep trying to circumvent my own security!
[color=blue]
> The reason for a lack of responses is not because nobody is interested
> in better security for Access, but rather because many of us have
> looked into this problem in some depth, and concluded, unfortunately,
> that there is no good solution. This is not just to say that 100%
> effectiveness is unachievable, but rather, that it is impossible to
> secure *any* Access database beyond the point where it can be
> desecured within seconds and a handful of lines of code, or within
> minutes if done manually.[/color]

Within seconds by you perhaps! My initial spur to look into this in greater
detail is to stop casual 'mucking about' with the database. If I can make
that damn difficult to do I'll have achieved my aim, in this case. In this
organisation it's almost certain that none of the users would have the skill
to get round a combination of Access and/or NT restrictions, and of course
if they go to MIS and ask them to lift those restrictions then that's fine.
The same would apply, presumably, to a server db.
[color=blue]
> You simply need a server-based rdbms if you
> wish to deliver any remote level of meaningful security to your
> client's databases.[/color]

There's not remote access to this db, it's on a LAN. Not quite sure what you
meant there.
[color=blue]
> Both are fatally flawed and trivial to de-secure.[/color]

As I said, trivial to you perhaps. But it's not really people with your
skill level that worry me. It's the maniacs who casually copy mdb files and
think they've got the data, which they may or may not have and then use that
'version' and it all get's out of sync etc. etc.

Thanks for you input.

Yours, Mike MacSween

[Larry Linson]

Re: Security - more complex than I thought

"Mike MacSween" wrote
[color=blue]
> Within seconds by you perhaps! My initial
> spur to look into this in greater detail is to
> stop casual 'mucking about' with the database.
> If I can make that damn difficult to do I'll have
> achieved my aim, in this case. In this organi-
> sation it's almost certain that none of the users
> would have the skill . . .[/color]
[color=blue]
> As I said, trivial to you perhaps. But it's not
> really people with your skill level that worry
> me. It's the maniacs who casually copy mdb
> files and think they've got the data, which they
> may or may not have and then use that
> 'version' and it all get's out of sync etc. etc.[/color]

If they have permission to use the database, I don't know how you can
prevent this scenario. They must have full permissions on the folders to be
able to _use_ it, it is trivial in Windows to copy a file, and they'll
already have permissions in Access security to use it. They don't have to
break security to do any of this, Mike.

And, there aren't many people anywhere in the world with the kind of skill
that Peter has in regard to Access / Jet internals. He does not break
security for clients (a position which makes perfect sense to me given the
litigious nature of our society), but anyone with US$150 can find on the
Internet and buy code that will break user/group security in a flash.

There's even a _free_ copy available of software to break user/group
security on an Access 97 database!

[cafe]

Re: Security - more complex than I thought


"Larry Linson" <bouncer@localh ost.not> wrote in message
news:6ZUsb.5220 4$p9.33254@nwrd dc02.gnilink.ne t...[color=blue]
> "Mike MacSween" wrote
>[color=green]
> > Within seconds by you perhaps! My initial
> > spur to look into this in greater detail is to
> > stop casual 'mucking about' with the database.
> > If I can make that damn difficult to do I'll have
> > achieved my aim, in this case. In this organi-
> > sation it's almost certain that none of the users
> > would have the skill . . .[/color]
>[color=green]
> > As I said, trivial to you perhaps. But it's not
> > really people with your skill level that worry
> > me. It's the maniacs who casually copy mdb
> > files and think they've got the data, which they
> > may or may not have and then use that
> > 'version' and it all get's out of sync etc. etc.[/color]
>
> If they have permission to use the database, I don't know how you can
> prevent this scenario. They must have full permissions on the folders to[/color]
be[color=blue]
> able to _use_ it, it is trivial in Windows to copy a file, and they'll
> already have permissions in Access security to use it. They don't have to
> break security to do any of this, Mike.
>
> And, there aren't many people anywhere in the world with the kind of skill
> that Peter has in regard to Access / Jet internals. He does not break
> security for clients (a position which makes perfect sense to me given the
> litigious nature of our society), but anyone with US$150 can find on the
> Internet and buy code that will break user/group security in a flash.
>
> There's even a _free_ copy available of software to break user/group
> security on an Access 97 database![/color]


AFAIK, those products do not "break security" in terms of producing a fully
desecured database. They just reverse-engineerin the passwords from a
workgroup file. That is not the same thing, eg. when there is no workgroup
file, or the workgroup file does not contain any Admins group users, or the
workgroup file is not the one that the database was created against.

So those products produce the same affect as finding a workmate's password
written on a PostIt note. That is bad - no doubt about it - but it does not
necessaruly give you unrestricted access to the database.

TC


TC

[Larry Linson]

Re: Security - more complex than I thought

I believe the most recent generation gives you the Owner ID and PID (SID?
whateverID?), from the database itself. Being able to identify yourself as
the owner of the database is just about as close to unrestricted access as
you're likely to get. And the "breaker" software does have the capability to
expose the sensitive _data_ in a database.

But, the worrisome situation Mike described does not appear to require
breaking into anything -- any user will, I fear, have all the permissions to
do that.

Larry


"cafe" <a@b.c.d> wrote in message news:1068776334 .449528@teuthos ...[color=blue]
>
> "Larry Linson" <bouncer@localh ost.not> wrote in message
> news:6ZUsb.5220 4$p9.33254@nwrd dc02.gnilink.ne t...[color=green]
> > "Mike MacSween" wrote
> >[color=darkred]
> > > Within seconds by you perhaps! My initial
> > > spur to look into this in greater detail is to
> > > stop casual 'mucking about' with the database.
> > > If I can make that damn difficult to do I'll have
> > > achieved my aim, in this case. In this organi-
> > > sation it's almost certain that none of the users
> > > would have the skill . . .[/color]
> >[color=darkred]
> > > As I said, trivial to you perhaps. But it's not
> > > really people with your skill level that worry
> > > me. It's the maniacs who casually copy mdb
> > > files and think they've got the data, which they
> > > may or may not have and then use that
> > > 'version' and it all get's out of sync etc. etc.[/color]
> >
> > If they have permission to use the database, I don't know how you can
> > prevent this scenario. They must have full permissions on the folders to[/color]
> be[color=green]
> > able to _use_ it, it is trivial in Windows to copy a file, and they'll
> > already have permissions in Access security to use it. They don't have[/color][/color]
to[color=blue][color=green]
> > break security to do any of this, Mike.
> >
> > And, there aren't many people anywhere in the world with the kind of[/color][/color]
skill[color=blue][color=green]
> > that Peter has in regard to Access / Jet internals. He does not break
> > security for clients (a position which makes perfect sense to me given[/color][/color]
the[color=blue][color=green]
> > litigious nature of our society), but anyone with US$150 can find on the
> > Internet and buy code that will break user/group security in a flash.
> >
> > There's even a _free_ copy available of software to break user/group
> > security on an Access 97 database![/color]
>
>
> AFAIK, those products do not "break security" in terms of producing a[/color]
fully[color=blue]
> desecured database. They just reverse-engineerin the passwords from a
> workgroup file. That is not the same thing, eg. when there is no workgroup
> file, or the workgroup file does not contain any Admins group users, or[/color]
the[color=blue]
> workgroup file is not the one that the database was created against.
>
> So those products produce the same affect as finding a workmate's password
> written on a PostIt note. That is bad - no doubt about it - but it does[/color]
not[color=blue]
> necessaruly give you unrestricted access to the database.
>
> TC
>
>
> TC
>
>
>[/color]

[TC]

Re: Security - more complex than I thought

"Larry Linson" <bouncer@localh ost.not> wrote in message
news:wCYsb.4124 3$n6.15194@nwrd dc03.gnilink.ne t...
[color=blue]
> I believe the most recent generation gives you the Owner ID and PID (SID?
> whateverID?), from the database itself. Being able to identify yourself as
> the owner of the database is just about as close to unrestricted access as
> you're likely to get.[/color]

Not so! It is a common misconception that the owner of the database, has
unrestrcted access to every object in the database. That is not actyually
so. It is easy to produce a database that is owned by the stndard Admin user
(for example), but contains one, several or >many< objects to which the
Admin user does not have full permissions - and can not acquire full
permissions.

For proof of this, see the following google message ID:
<1040611790.281 616@teuthos>

Or, check out the ShrinkerStretch er demo database. That database is owned by
the standard Admin user, but methinks you will not be able to open the main
code module!

Cheers,
TC


[color=blue]
> And the "breaker" software does have the capability to
> expose the sensitive _data_ in a database.
>
> But, the worrisome situation Mike described does not appear to require
> breaking into anything -- any user will, I fear, have all the permissions[/color]
to[color=blue]
> do that.
>
> Larry
>
>
> "cafe" <a@b.c.d> wrote in message news:1068776334 .449528@teuthos ...[color=green]
> >
> > "Larry Linson" <bouncer@localh ost.not> wrote in message
> > news:6ZUsb.5220 4$p9.33254@nwrd dc02.gnilink.ne t...[color=darkred]
> > > "Mike MacSween" wrote
> > >
> > > > Within seconds by you perhaps! My initial
> > > > spur to look into this in greater detail is to
> > > > stop casual 'mucking about' with the database.
> > > > If I can make that damn difficult to do I'll have
> > > > achieved my aim, in this case. In this organi-
> > > > sation it's almost certain that none of the users
> > > > would have the skill . . .
> > >
> > > > As I said, trivial to you perhaps. But it's not
> > > > really people with your skill level that worry
> > > > me. It's the maniacs who casually copy mdb
> > > > files and think they've got the data, which they
> > > > may or may not have and then use that
> > > > 'version' and it all get's out of sync etc. etc.
> > >
> > > If they have permission to use the database, I don't know how you can
> > > prevent this scenario. They must have full permissions on the folders[/color][/color][/color]
to[color=blue][color=green]
> > be[color=darkred]
> > > able to _use_ it, it is trivial in Windows to copy a file, and they'll
> > > already have permissions in Access security to use it. They don't have[/color][/color]
> to[color=green][color=darkred]
> > > break security to do any of this, Mike.
> > >
> > > And, there aren't many people anywhere in the world with the kind of[/color][/color]
> skill[color=green][color=darkred]
> > > that Peter has in regard to Access / Jet internals. He does not break
> > > security for clients (a position which makes perfect sense to me given[/color][/color]
> the[color=green][color=darkred]
> > > litigious nature of our society), but anyone with US$150 can find on[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > Internet and buy code that will break user/group security in a flash.
> > >
> > > There's even a _free_ copy available of software to break user/group
> > > security on an Access 97 database![/color]
> >
> >
> > AFAIK, those products do not "break security" in terms of producing a[/color]
> fully[color=green]
> > desecured database. They just reverse-engineerin the passwords from a
> > workgroup file. That is not the same thing, eg. when there is no[/color][/color]
workgroup[color=blue][color=green]
> > file, or the workgroup file does not contain any Admins group users, or[/color]
> the[color=green]
> > workgroup file is not the one that the database was created against.
> >
> > So those products produce the same affect as finding a workmate's[/color][/color]
password[color=blue][color=green]
> > written on a PostIt note. That is bad - no doubt about it - but it does[/color]
> not[color=green]
> > necessaruly give you unrestricted access to the database.
> >
> > TC
> >
> >
> > TC
> >
> >
> >[/color]
>
>[/color]

[Michael \(michka\) Kaplan [MS]]

Re: Security - more complex than I thought

There is at least one method that DOES exist in the wild that does not
require an MDW. It can get into any database and any object in a database,
whatsoever. There are also several methods that use MDWs to get into it in
various ways (some of which require an account with permissions, others
which do not).

Before I joined up with Microsoft full-time, I was asked by several
different companies around the world to prove this for them -- they flew me
there, they signed a document that required them to never use the methods I
present, I did a presentation that proved various methods, and then I flew
home. I had a money-back guarantee for anyone who is not convinced and no
one ever asked for their money back.

The myth of secure MDBs is just that -- a myth.


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


"TC" <a@b.c.d> wrote in message news:1068785677 .801574@teuthos ...[color=blue]
> "Larry Linson" <bouncer@localh ost.not> wrote in message
> news:wCYsb.4124 3$n6.15194@nwrd dc03.gnilink.ne t...
>[color=green]
> > I believe the most recent generation gives you the Owner ID and PID[/color][/color]
(SID?[color=blue][color=green]
> > whateverID?), from the database itself. Being able to identify yourself[/color][/color]
as[color=blue][color=green]
> > the owner of the database is just about as close to unrestricted access[/color][/color]
as[color=blue][color=green]
> > you're likely to get.[/color]
>
> Not so! It is a common misconception that the owner of the database, has
> unrestrcted access to every object in the database. That is not actyually
> so. It is easy to produce a database that is owned by the stndard Admin[/color]
user[color=blue]
> (for example), but contains one, several or >many< objects to which the
> Admin user does not have full permissions - and can not acquire full
> permissions.
>
> For proof of this, see the following google message ID:
> <1040611790.281 616@teuthos>
>
> Or, check out the ShrinkerStretch er demo database. That database is owned[/color]
by[color=blue]
> the standard Admin user, but methinks you will not be able to open the[/color]
main[color=blue]
> code module!
>
> Cheers,
> TC
>
>
>[color=green]
> > And the "breaker" software does have the capability to
> > expose the sensitive _data_ in a database.
> >
> > But, the worrisome situation Mike described does not appear to require
> > breaking into anything -- any user will, I fear, have all the[/color][/color]
permissions[color=blue]
> to[color=green]
> > do that.
> >
> > Larry
> >
> >
> > "cafe" <a@b.c.d> wrote in message news:1068776334 .449528@teuthos ...[color=darkred]
> > >
> > > "Larry Linson" <bouncer@localh ost.not> wrote in message
> > > news:6ZUsb.5220 4$p9.33254@nwrd dc02.gnilink.ne t...
> > > > "Mike MacSween" wrote
> > > >
> > > > > Within seconds by you perhaps! My initial
> > > > > spur to look into this in greater detail is to
> > > > > stop casual 'mucking about' with the database.
> > > > > If I can make that damn difficult to do I'll have
> > > > > achieved my aim, in this case. In this organi-
> > > > > sation it's almost certain that none of the users
> > > > > would have the skill . . .
> > > >
> > > > > As I said, trivial to you perhaps. But it's not
> > > > > really people with your skill level that worry
> > > > > me. It's the maniacs who casually copy mdb
> > > > > files and think they've got the data, which they
> > > > > may or may not have and then use that
> > > > > 'version' and it all get's out of sync etc. etc.
> > > >
> > > > If they have permission to use the database, I don't know how you[/color][/color][/color]
can[color=blue][color=green][color=darkred]
> > > > prevent this scenario. They must have full permissions on the[/color][/color][/color]
folders[color=blue]
> to[color=green][color=darkred]
> > > be
> > > > able to _use_ it, it is trivial in Windows to copy a file, and[/color][/color][/color]
they'll[color=blue][color=green][color=darkred]
> > > > already have permissions in Access security to use it. They don't[/color][/color][/color]
have[color=blue][color=green]
> > to[color=darkred]
> > > > break security to do any of this, Mike.
> > > >
> > > > And, there aren't many people anywhere in the world with the kind of[/color]
> > skill[color=darkred]
> > > > that Peter has in regard to Access / Jet internals. He does not[/color][/color][/color]
break[color=blue][color=green][color=darkred]
> > > > security for clients (a position which makes perfect sense to me[/color][/color][/color]
given[color=blue][color=green]
> > the[color=darkred]
> > > > litigious nature of our society), but anyone with US$150 can find on[/color][/color]
> the[color=green][color=darkred]
> > > > Internet and buy code that will break user/group security in a[/color][/color][/color]
flash.[color=blue][color=green][color=darkred]
> > > >
> > > > There's even a _free_ copy available of software to break user/group
> > > > security on an Access 97 database!
> > >
> > >
> > > AFAIK, those products do not "break security" in terms of producing a[/color]
> > fully[color=darkred]
> > > desecured database. They just reverse-engineerin the passwords from a
> > > workgroup file. That is not the same thing, eg. when there is no[/color][/color]
> workgroup[color=green][color=darkred]
> > > file, or the workgroup file does not contain any Admins group users,[/color][/color][/color]
or[color=blue][color=green]
> > the[color=darkred]
> > > workgroup file is not the one that the database was created against.
> > >
> > > So those products produce the same affect as finding a workmate's[/color][/color]
> password[color=green][color=darkred]
> > > written on a PostIt note. That is bad - no doubt about it - but it[/color][/color][/color]
does[color=blue][color=green]
> > not[color=darkred]
> > > necessaruly give you unrestricted access to the database.
> > >
> > > TC
> > >
> > >
> > > TC
> > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Mike MacSween]

Re: Security - more complex than I thought

"Larry Linson" <bouncer@localh ost.not> wrote in message
news:6ZUsb.5220 4$p9.33254@nwrd dc02.gnilink.ne t...
[color=blue]
> If they have permission to use the database, I don't know how you can
> prevent this scenario. They must have full permissions on the folders to[/color]
be[color=blue]
> able to _use_ it,[/color]

I don't think so. They have to have _some_ permissions on the folder. That
is
different to the permissions they need to have to the back end data file (if
that is the way it's implemented).

To repeat. I defined some users (NT users, that is). I gave them certain
permissions on the folder:

Write, Delete Subfolders/Files. That last may not be necessary if you're not
bothered about the ldb being deleted when the last user is out of the back
end. And I specifically deny them List Folder/Read Data.

On the BE file contained in that folder give them read and write if you
want.

I logged on as one of those users. I couldn't get to the back end data file
doing an ordinary windows explorer browse.

Perhaps one of you could try the same test. I might actually be talking
sense. Or at least to know what big mistake I've made.
[color=blue]
> it is trivial in Windows to copy a file, and they'll
> already have permissions in Access security to use it. They don't have to
> break security to do any of this, Mike.[/color]

It didn't seem trivial to me. I couldn't find it in F3 either. And they
won't have permission in Access security unless I've given it too them.

David's idea of using hidden shares seems to offer an extra level of
security too.

My point? Quite simply this. That I have often heard the opinion expressed
like this -

'Access can't be made secure, so don't bother'. Well one of the ideas that
because it's a file based system you have to give users full access to the
file seems to me to be NOT TRUE. Perhaps one of you would like to try doing
what I just did, as described above. I couldn't get at the file, certainly
not behaving as an ordinary user. I'm not bothered about high powered
hackers or people with Peter's skill level. If I was then sure, Access might
not be an appropriate solution. I'm bothered about users, perhaps even
fairly sophisticated ones RELATIVELY SPEAKING.

Security isn't an abolute is it? There's isn't such a thing as 100% security
or 0% security. Tell me this, is there a software development company
anywhere in the world who has ever signed a contract which offered total
security for a system it was developing, with unlimited liability if that
security was ever breached? I doubt it (not that we'd know if they had).

I'm still exploring various techniques. I haven't really explored Access
built in security fully. But it's not difficult to think of more and more
things to make it difficult for unauthorised users to gain access:

1. David's hidden share seems like a good idea.
2. Obscurely named data files - d93kl03ekdskls0 dkfjds.dat instead of
myDatabaseBacke nd.mdb
3. Frequently changing the name of the BE data file. Or even it's network
location.
4. If you have admin privileges disabling the linked table manager.
5. Disable, through code, the bypass startup key.
6. And of course DIY security, which my not be complex, but if you've
implemented it in some way unique to your app at least there won't be a
commonly available crack.

Then extensive logging of NT use, so that at least it's possible to see WHO
has accessed the db, even if we can't be sure of stopping them doing
something naughty.

Yes, and here's the response. 'If you're going to go to all that trouble you
may as well use a server database'. So, there's no cracks or hacks for SQL
server, Oracle etc? Perhaps not yet. And we're willing to pay the licences,
and the extra development costs are we?

Many of the techniques/ideas I've described above are once only things. Once
you've done it once you know how to do it again.

We live in an Access world here in CDMA. We know that Access isn't 100%
secure. We forget that most people don't know the difference between Windows
Explorer and Internet Explorer. Or what a network drive is. The burglers who
smashed the glass in my backdoor, reached in and turned the Yale lock know
how to break into a house. Now that it's a solid wooden door with a mortice
lock they can't do that. Another burgler might be willing to try harder next
time. So what? It doesn't mean I don't lock up when I leave the house. And
it doesn't mean that I personally am not willing to try to make it difficult
for anybody except the most determined person, with a very in-depth
knowledge of Access, VBA and NT file permissions, to get at the data without
authority.

Yours, Mike MacSween

[Michael \(michka\) Kaplan [MS]]

Re: Security - more complex than I thought

All I can tell you is that you are wrong, and there are tools that exist
that a person can find which will get into the database. All a person needs
is access to the FILE (no need to copy, etc.) and they can break in to it.


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Mike MacSween" <mike.macsween. nospam@btintern et.com> wrote in message
news:3fb4e7cf$0 $52884$5a6aecb4 @news.aaisp.net .uk...[color=blue]
> "Larry Linson" <bouncer@localh ost.not> wrote in message
> news:6ZUsb.5220 4$p9.33254@nwrd dc02.gnilink.ne t...
>[color=green]
> > If they have permission to use the database, I don't know how you can
> > prevent this scenario. They must have full permissions on the folders to[/color]
> be[color=green]
> > able to _use_ it,[/color]
>
> I don't think so. They have to have _some_ permissions on the folder. That
> is
> different to the permissions they need to have to the back end data file[/color]
(if[color=blue]
> that is the way it's implemented).
>
> To repeat. I defined some users (NT users, that is). I gave them certain
> permissions on the folder:
>
> Write, Delete Subfolders/Files. That last may not be necessary if you're[/color]
not[color=blue]
> bothered about the ldb being deleted when the last user is out of the back
> end. And I specifically deny them List Folder/Read Data.
>
> On the BE file contained in that folder give them read and write if you
> want.
>
> I logged on as one of those users. I couldn't get to the back end data[/color]
file[color=blue]
> doing an ordinary windows explorer browse.
>
> Perhaps one of you could try the same test. I might actually be talking
> sense. Or at least to know what big mistake I've made.
>[color=green]
> > it is trivial in Windows to copy a file, and they'll
> > already have permissions in Access security to use it. They don't have[/color][/color]
to[color=blue][color=green]
> > break security to do any of this, Mike.[/color]
>
> It didn't seem trivial to me. I couldn't find it in F3 either. And they
> won't have permission in Access security unless I've given it too them.
>
> David's idea of using hidden shares seems to offer an extra level of
> security too.
>
> My point? Quite simply this. That I have often heard the opinion expressed
> like this -
>
> 'Access can't be made secure, so don't bother'. Well one of the ideas that
> because it's a file based system you have to give users full access to the
> file seems to me to be NOT TRUE. Perhaps one of you would like to try[/color]
doing[color=blue]
> what I just did, as described above. I couldn't get at the file, certainly
> not behaving as an ordinary user. I'm not bothered about high powered
> hackers or people with Peter's skill level. If I was then sure, Access[/color]
might[color=blue]
> not be an appropriate solution. I'm bothered about users, perhaps even
> fairly sophisticated ones RELATIVELY SPEAKING.
>
> Security isn't an abolute is it? There's isn't such a thing as 100%[/color]
security[color=blue]
> or 0% security. Tell me this, is there a software development company
> anywhere in the world who has ever signed a contract which offered total
> security for a system it was developing, with unlimited liability if that
> security was ever breached? I doubt it (not that we'd know if they had).
>
> I'm still exploring various techniques. I haven't really explored Access
> built in security fully. But it's not difficult to think of more and more
> things to make it difficult for unauthorised users to gain access:
>
> 1. David's hidden share seems like a good idea.
> 2. Obscurely named data files - d93kl03ekdskls0 dkfjds.dat instead of
> myDatabaseBacke nd.mdb
> 3. Frequently changing the name of the BE data file. Or even it's network
> location.
> 4. If you have admin privileges disabling the linked table manager.
> 5. Disable, through code, the bypass startup key.
> 6. And of course DIY security, which my not be complex, but if you've
> implemented it in some way unique to your app at least there won't be a
> commonly available crack.
>
> Then extensive logging of NT use, so that at least it's possible to see[/color]
WHO[color=blue]
> has accessed the db, even if we can't be sure of stopping them doing
> something naughty.
>
> Yes, and here's the response. 'If you're going to go to all that trouble[/color]
you[color=blue]
> may as well use a server database'. So, there's no cracks or hacks for SQL
> server, Oracle etc? Perhaps not yet. And we're willing to pay the[/color]
licences,[color=blue]
> and the extra development costs are we?
>
> Many of the techniques/ideas I've described above are once only things.[/color]
Once[color=blue]
> you've done it once you know how to do it again.
>
> We live in an Access world here in CDMA. We know that Access isn't 100%
> secure. We forget that most people don't know the difference between[/color]
Windows[color=blue]
> Explorer and Internet Explorer. Or what a network drive is. The burglers[/color]
who[color=blue]
> smashed the glass in my backdoor, reached in and turned the Yale lock know
> how to break into a house. Now that it's a solid wooden door with a[/color]
mortice[color=blue]
> lock they can't do that. Another burgler might be willing to try harder[/color]
next[color=blue]
> time. So what? It doesn't mean I don't lock up when I leave the house. And
> it doesn't mean that I personally am not willing to try to make it[/color]
difficult[color=blue]
> for anybody except the most determined person, with a very in-depth
> knowledge of Access, VBA and NT file permissions, to get at the data[/color]
without[color=blue]
> authority.
>
> Yours, Mike MacSween
>
>[/color]