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)
116  7273 
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" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . 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)
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" <mi******************@btinternet.com>
Newsgroups: comp.databases.ms-access
Sent: Monday, November 10, 2003 10:16 AM
Subject: Security - more complex than I thought 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)
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . 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]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com... 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.
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
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . "Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com... 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.
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'
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
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" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . 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)
On Mon, 10 Nov 2003 21:46:13 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access: 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.
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.
What approach do you use to Access security? The built in model or do you
'roll your own'
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
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:ee********************************@4ax.com... On Mon, 10 Nov 2003 21:46:13 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
Thanks for you reply Peter
As you've no doubt found out, NT permissions are not enough to fill
the gaps in Access security.
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!
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.
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.
You simply need a server-based rdbms if you
wish to deliver any remote level of meaningful security to your
client's databases.
There's not remote access to this db, it's on a LAN. Not quite sure what you
meant there.
Both are fatally flawed and trivial to de-secure.
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
"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 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!
"Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net... "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 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!
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
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...
"Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net... "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 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!
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" <bo*****@localhost.not> wrote in message
news:wC******************@nwrddc03.gnilink.net... 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.
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.281616@teuthos>
Or, check out the ShrinkerStretcher 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
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...
"Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net... "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
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!
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
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... "Larry Linson" <bo*****@localhost.not> wrote in message
news:wC******************@nwrddc03.gnilink.net...
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.
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.281616@teuthos>
Or, check out the ShrinkerStretcher 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
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...
"Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net...
> "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 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!
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" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net... 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,
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.
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.
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 - d93kl03ekdskls0dkfjds.dat instead of
myDatabaseBackend.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
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" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . "Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net...
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,
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.
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.
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 - d93kl03ekdskls0dkfjds.dat instead of
myDatabaseBackend.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]" <mi*****@online.microsoft.com> wrote in
message news:3f******@news.microsoft.com... 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.
Which thing that I said was 'wrong'?
As well as telling me that I am wrong (about something or other so far
unspecified) perhaps you could tell me what happened when YOU duplicated the
situation which I have just described. You did try that didn't you? To see
whether what I posited as an approach might have some grain of merit in it.
You, like many here, seem to have COMPLETELY MISUNDERSTOOD the point. I'm
not saying that Access security is good, bad or indifferent. Because, as
I've said before, security is a relative term. But I will say this. No
application that any developer on the surface of the globe has ever
developed is 100% secure. Go on. Prove it. Tell me about one that is. That
hasn't never been compromised and can be proved beyond doubt to be 100%
secure.
All I can tell you is that you are right. But not 100%. If a 'person' has
access to the FILE they can break into. If. If they have access to the file.
And who is this 'person'. Is it Amanda, our clerical assistant? Or is it
Timothy, our head of department (department being Music)? Or is Anthony, our
head of MIS? Have they the ability or knowledge to bypass NT permissions and
Access security and then 'break in to it'. Do you know? Which 'persons' did
you have in mind when you said that? And what will they do when they 'break
into it' (whatever that means - read the data, alter the data?).
I'm not damn well saying that it isn't possible to bypass Access security
and/or NT permissions. I'm saying it can be made easy, hard, very hard or
extremely hard FOR MOST PEOPLE.
Yours, Mike MacSween
TC,
On Fri, 14 Nov 2003 14:39:57 +1200, "TC" <a@b.c.d> wrote in
comp.databases.ms-access: 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
This is true.
- and can not acquire full permissions.
And this is false.
As Michka said, it is not at all difficult to break a secured mdb
without any mdw. Yes, it is good practice to distribute a limited mdw
that does not contain the owner of the db or any of the constituent
objects, but while this limits the 'privilege escalation'
vulnerability (where a limited user can escalate his privileges to
that of the most privileged user within the workgroup) it does not in
any way prevent the user from simply reading out the ownership
information on the db and objects directly from the mdb itself, and
creating dummy user accounts that have the required SID for ownership.
While Michka may have turned this into a lucrative traveling show
(kudos Michka - wish I'd thought of that!), it can be proven in a much
more direct fashion.
TC, I know you're at least somewhat (and perhaps greatly)
knowledgeable about Access security and its vulnerabilities, so this
next comment is more for Mike than you, but here goes. It is a very
big mistake to assume that such vulnerabilities are only known or
knowable by a select few. I often have people tell me, 'well, sure,
Peter, you may know how to break in, but you're a specialist in such
matters'. I wish I could debunk this myth. The problems with
Access/JEt security are very significant and DO NOT require expert or
specialized knowledge to bypass it. Michka and I can do all the
desecuring examples we like and people can still say, 'well, ok, but
you guys know something special'. The only way to *prove* how trivial
security is to bypass (without mdw's, special tools, or any prior
knowledge of a secured mdb's contents) is to publish the code to do
so. I don't want to do this because it has obvious possibilities for
abuse. Michka could do likewise, of course (and has, to his credit,
in one special case). It would be far better if people would accept
that Access/Jet security is very weak indeed, rather than thinking
that it's just a matter of the right tweaking, and effective security
can be provided for with Jet. Part of the problem, is, of course,
that jet is a file-server based rdbms, and not a service, and as such,
has inherent weaknesses that can not be overcome as do other similarly
architected systems, but part of the problem is also the weakness of
the implementation. Taken together, they spell doom for any
meaningful level of security in Jet. This really can not be over
stressed.
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
On Fri, 14 Nov 2003 12:32:20 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access: "Larry Linson" <bo*****@localhost.not> wrote in message
news:6Z******************@nwrddc02.gnilink.net. ..
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,
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).
You are correct, in a limited way, Mike.
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.
Right, and then you tried going after the file directly (by specifying
its full path and name instead of simply browsing the parent folder),
and what did you find? I thought so.
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.
Larry's correct.
David's idea of using hidden shares seems to offer an extra level of
security too.
True, if combined with MDE's.
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.
Arggh! You don't need to give them FULL access, but you do need to
give them enough access for them to be able to violate security. You
could set up Access/JEt in a way that limited the users ability to
overwrite the real backend by a variety of techniques combined which
would also limit effective use of the db itself (ie, and is therefore
unworkable for most situations) but you unequivocally can not prevent
the secured database from being taken and desecured completely.
Period.
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.
Forget about fairly sophisticated ones. Try fairly unsophisticated
ones who know hot to type 'google.com' into their browser.
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
Yes. It's based on specs and requirements. Given a certain
environment, various vendors offer guaranteed security.
, with unlimited liability if that security was ever breached?
Not unlimited liability, but liability, yes.
Well,
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:
I encourage you to pursue this investigation. But do so with the
understanding that you should weigh each new idea both on its
individual merits as well as on whether it complements other features,
or is weakened by them. Simply layering security feature upon feature
does not necessarily strengthen security further, and can even lead to
weaker security.
1. David's hidden share seems like a good idea.
It is.
2. Obscurely named data files - d93kl03ekdskls0dkfjds.dat instead of
myDatabaseBackend.mdb
Well, yes, but this is terribly trivial. Your data file will
typically be the largest file, and only the most naive of users are
unaware that you can open files of type *.* rather than
*.REGULAR_SUFFIX for any app.
3. Frequently changing the name of the BE data file. Or even it's network
location.
I think this is a waste of time. Users who would break your security
are not watching your app over a period of time. They would simply
come in and try to grab it at a specific point in time, and regardless
of where your file is and what's its called, it can't jump around
within a single point in time.
4. If you have admin privileges disabling the linked table manager.
Worthless.
5. Disable, through code, the bypass startup key.
Trivial to bypass, but should be done anyway.
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.
That's true, but carries a mistaken assumption. Your DIY security
will indeed not be subject to the common cracking tools out there, and
this is a good reason to choose (when possible) non-mainstream
software products as long as they have active and competent support
from a security conscious vendor, but this isn't relevant here. Your
DIY security can not be enforced across the board, and as such, it
only works when your app is used as intended, and perhaps in a limited
number of additional scenarios. But the point here is that your app
WILL NOT be used as intended by the malevolent user, and so DIT
security is not very helpful in protecting your app from anything but
the unintentionally errant user.
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.
Arghh! This is not very helpful in preventing misuse by authorized
users (ie, privilege escalation attacks), and is sort of pointless
against external attacks (because once your app's security has been
bypassed and its data exposed, a large part of the battle has already
been lost).
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?
There are problems with all software, but client/server-based (or,
lets call them service-based) rdbms are inherently safer because they
do not expose their raw file space to the users. In other words, it
is only flaws in the underlying o/s or flaws in the implementation of
their security model that you are exposed to, and not weaknesses in
their file storage mechanisms. This is a huge difference. No Access
database can be decently secured - period. Service-based rdbms's CAN
be secured. Whether they are or not is of course a separate question.
And just because licensing costs may be prohibitive for many companies
in no way makes Access security any more reliable.
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.
Which has precisely the same level of truth for any attacker.
We live in an Access world here in CDMA. We know that Access isn't 100%
secure.
Or 90%, or 50% or 25%.
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.
Very true. And if you are happy with your DIY security on Access
databases, then that's fine. But the impression given here is that
you are telling your clients that the security offered by your DIY
security is 'pretty good' and that is where I disagree with you
strongly. Access security is terribly weak. Your DIY security, if
not combined with Access security, is even weaker. Your DIY security
combined with Access security may indeed be better than Access
security alone, but (a) that should be verified by at least limited
peer review and (b) even then, its not saying much. You should tell
your clients that very little meaningful security is offered by such
systems. If they are comfortable with that, then great, but if you
tell them anything stronger, you are either lying to them, or letting
your naivety harm your clients interests. That's my point.
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,
On Fri, 14 Nov 2003 14:40:31 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access: You, like many here, seem to have COMPLETELY MISUNDERSTOOD the point. I'm
not saying that Access security is good, bad or indifferent. Because, as
I've said before, security is a relative term.
Relativity doesn't mean a complete inability to pass judgement - just
that judgements will vary based on perspective. You can indeed say
that Access security is quite poor even with the understanding that
this is relative.
Otherwise, for example, simply changing the suffix from mdb to xyz on
a non-secured database would be, in your view, a security measure that
one could not say was good, bad or anything else. After all, security
is relative, right, and most of the worlds population would not be
able to break into your 'secured' file. Relativity is not just a
numbers game (most of the population would indeed be incapable of
breaking into your suffix-changed file because most of them lack
access to a computer, and even those that have access to a computer,
would lack access to your specific file, and even those with access to
a computer and your file may very well not understand your language,
etc, etc). Relativity (in ref to security) means that security models
should be judged on their applicability to task. More on this
below...
All I can tell you is that you are right. But not 100%. If a 'person' has
access to the FILE they can break into. If. If they have access to the file.
And who is this 'person'. Is it Amanda, our clerical assistant? Or is it
Timothy, our head of department (department being Music)? Or is Anthony, our
head of MIS? Have they the ability or knowledge to bypass NT permissions and
Access security and then 'break in to it'. Do you know? Which 'persons' did
you have in mind when you said that? And what will they do when they 'break
into it' (whatever that means - read the data, alter the data?).
Ah yes, we can not talk about security problems in a technology or
architecture without first having in mind a particular user and a
particular malevolent goal. Ridiculous. Access security is weak
because it protects against very few types of attacks, and none
effectively. You say people misunderstand your point, but I would
posit that we don't. We understand what you're saying. You're basic
thrust is given a naive enough set of users, Access's weak security
might actually be effective, or better yet, maybe DIY security will do
the trick. Given a very controlled environment, what you say is true,
but such an environment doesn't really exist today. Are you positive
that none of the users know how to use a search engine. Are you
positive that even if they are clueless now, that they will never
learn of the internet? Are you equally positive their kids are just
as clueless? And their friends? And that they do not have any
ulterior motives? And that they never will have any? The whole point
of effective (and that doesn't at all mean perfect - just meaningful)
security is that it protects against likely and reasonably possible
attacks/threats. Access security doesn't.
Essentially, what you're saying above is that Michka doesn't know the
user base for your specific example, and so he can't speak with any
authority about the strength or viability of the security system you
will provide. You're implying of course, that you do know them. Are
you going to stipulate that your DIY security will be effective
against Amanda and Timothy (presumably not Anthony) provided their
situation doesn't change, motives remain constant, knowledge doesn't
improve, and that nobody else ever gets hired, etc. etc?
Of course you aren't.
My point is that you over-estimate the strength provided by Access
security, and it appears, your own DIY security, and that, despite
your belief to the contrary, I am not over-estimating the capabilities
of your client's current and future users.
If you told your client, 'hey, the security I'm building into this app
is pretty weak, but <nod, nod, wink, wink> look at your users and your
security needs - you'll be just fine with weak security' then I'd have
no problem with that.
I'm not damn well saying that it isn't possible to bypass Access security
and/or NT permissions. I'm saying it can be made easy, hard, very hard or
extremely hard FOR MOST PEOPLE.
And I'd agree, except that I'd limit it to saying that Access security
and (not or) NT permissions can make it at best moderately difficult
for the average user to bypass.
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
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:gg********************************@4ax.com...
Mike,
On Fri, 14 Nov 2003 14:40:31 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
I'm not damn well saying that it isn't possible to bypass Access security
and/or NT permissions. I'm saying it can be made easy, hard, very hard or
extremely hard FOR MOST PEOPLE.
And I'd agree, except that I'd limit it to saying that Access security
and (not or) NT permissions can make it at best moderately difficult
for the average user to bypass.
Case in point http://groups.google.com/groups?hl=e...0noaddress.com
Don't underestimate users' capabilities.
--
Joan Wild
Mike MacSween previously wrote: 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'.
Well I would be very surprised if they meant this comment in any other
way than regulating routine access to the application, which you CAN
implement after the fact.
In my view for >99.9% of all apps, the main practical benefit of security
(as opposed to the stated aim) is to protect the integrity of the
application. It's nothing at all to do with preventing someone stealing
the data. After all, which application on earth does not have query
facilities and export facilities built in.
So the relative 'crackability' of dbms's is largely irrelevant.
99.9% of all application users have as much interest in breaking an app's
security as they have in the price of rice in Uzbekistan. And are
incapable of breaking the simplest level of security.
Reading the Access security newsgroups for a while has been enough to
convince me that the most common solution to 'security' problems is 'hold
the shift key down when you open the database'. If people can't even deal
with this level of 'security' then a database password would stymie them
completely.
The danger group are app developers, who are likely to be more interested
in nicking the application design than the data.
Of course, where you are dealing with personal data or otherwise sensitive
data you have to be seen to be taking steps to discourage abuse/misuse/
whatever.
But true data security won't have arrived until the day the system admins
don't know what everybody's salary is. And pigs might finally fly.
Regards
Peter Russell mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>: 1. David's hidden share seems like a good idea.
2. Obscurely named data files - d93kl03ekdskls0dkfjds.dat instead
of myDatabaseBackend.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.
Most of these are "security by obscurity," which is really no
security at all.
But I wouldn't say that there's anything wrong with doing some of
these things, like hidden shares and non-intuitive file names, and
certainly there's nothing wrong with implementing Jet security.
If you understand what you're getting from these things and
acknowledge that you're only making it less likely for the casually
user to muck around with things, then I don't see a problem with
doing these things. None of them takes a great deal of time or
effort to implement.
I once implemented a system where users were only authorized to log
into the database for fixed lengths of time. I used a bunch of
algorithms hidden in secured code modules to encode data in a user
data table. It was based on obscurity that would not be crackable
by the people who we were attempting to restrict. It was
replicated, so we could change someone's logon privileges on a
daily basis, and the only way for the remote user to avoid getting
zapped out of the application would be to never replicate again.
I can't say it was a very good implementation, but it had certain
merit for the circumstances of the client in question (they had two
off-site subcontractors that they'd lost trust in). And we had to
slip the program upgrades out to them without them understanding
that we were upgrading the program in a way that could eventually
be used to keep them out of the database.
Now, either of these people could have hired someone with
Jet/Access expertise and cracking capabilities (this was before Jet
user-level security had been cracked, so far as I know, and both
the app and the data file were fully secured) to crack the whole
thing. But they'd have needed to know that it was *possible* to
hire someone to do that, and then they would have needed to find
someone to do it for them. Those two steps are not all that
trivial, in my estimation, especially for the personnel involved.
All this said, it's still only a minor level of protection, one
that's valuable, indeed, but still not particularly safe.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>: All I can tell you is that you are right. But not 100%. If a
'person' has access to the FILE they can break into. If. If they
have access to the file. And who is this 'person'. Is it Amanda,
our clerical assistant? Or is it Timothy, our head of department
(department being Music)? Or is Anthony, our head of MIS? Have
they the ability or knowledge to bypass NT permissions and Access
security and then 'break in to it'. Do you know? Which 'persons'
did you have in mind when you said that? And what will they do
when they 'break into it' (whatever that means - read the data,
alter the data?).
I'm not damn well saying that it isn't possible to bypass Access
security and/or NT permissions. I'm saying it can be made easy,
hard, very hard or extremely hard FOR MOST PEOPLE.
I think most people who respond as Michael did are simply misreading
your goal. You're not looking for security. You're looking to erect
as few barriers to the casual users.
All the things you've talked about will, indeed, be insurmountable
barriers to most casual users for all practical purposes, and I
think that's worth something, especially given that none of the
things you've proposed are all that difficult to implement.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc pm*****@pksolutions.com (Peter Miller) wrote in
<gg********************************@4ax.com>: If you told your client, 'hey, the security I'm building into this
app is pretty weak, but <nod, nod, wink, wink> look at your users
and your security needs - you'll be just fine with weak security'
then I'd have no problem with that.
I've done exactly (well, in so many words) that with every client
for whom I've built an Access application that used Jet user-level
security. My philosophy is that erecting any barrier protects you
from some useful number of attacks, even if not from all. When the
client considers the low level of protection unacceptable, we
discuss the costs of getting higher levels of protection. None of
my clients has ever chosen to go with anything more secure, based
on a cost/benefit analysis that was itself best on a gut-level
estimation of the risks involved.
Your argument is based on the idea that we've mis-estimated the
risk, and thus are under-rating the benefit of switching to a
platform with higher levels of security.
That's a reasonable argument.
But it's a rather different one from the one you appear to be
making.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc jw***@nospamtyenet.com (Joan Wild) wrote in
<bp********@enews1.newsguy.com>:
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:gg********************************@4ax.com.. .
Mike,
On Fri, 14 Nov 2003 14:40:31 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
>I'm not damn well saying that it isn't possible to bypass
>Access security and/or NT permissions. I'm saying it can be
>made easy, hard, very hard or extremely hard FOR MOST PEOPLE.
And I'd agree, except that I'd limit it to saying that Access
security and (not or) NT permissions can make it at best
moderately difficult for the average user to bypass.
Case in point
http://groups.google.com/groups?hl=e...=UTF-8&selm=3D
907C27.6010206%40noaddress.com
Don't underestimate users' capabilities.
The question assumes:
1. users know that there is such a thing as "Access security."
2. they know that it is crackable.
3. they know that their app uses it and is preventing them from
doing certain things so that they have the motivation to
investigate how to get around it.
The question asked gave them that information.
The assumption behind doing so is that anyone can figure that out.
But the fact is, most people don't know these things and that lack
of knowledge means that the barriers will keep some number of
people from doing things they shouldn't do.
Then you must ask yourself exactly what level of risk is acceptable
and compare that to the cost of getting the risk down to that
level.
It's perfectly reasonable to depend on Jet user-level security and
NT permissions and logging for a certain level of protection
against user exploits, given a certain determination by the
organization that the cost/benefit ration is appropriate for the
level of risk they are willing to be exposed to.
Many people under-rate the risks and over-rate the security gained
from obscurity.
But that's a different issue from whether or not there are any
scenarios where using the techniques Mike has outlined are
acceptable.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc pm*****@pksolutions.com (Peter Miller) wrote in
<gn********************************@4ax.com>: Your DIY security
will indeed not be subject to the common cracking tools out there,
and this is a good reason to choose (when possible) non-mainstream
software products as long as they have active and competent
support from a security conscious vendor, but this isn't relevant
here. Your DIY security can not be enforced across the board, and
as such, it only works when your app is used as intended, and
perhaps in a limited number of additional scenarios. But the
point here is that your app WILL NOT be used as intended by the
malevolent user, and so DIT security is not very helpful in
protecting your app from anything but the unintentionally errant
user.
But Mike is specifically talking about things that you can do that
erect barriers to prevent mis-use of the application and its data
by the regular users doing their usual tasks.
I think it's reasonable to do most of the things Mike has talked
about, as long as you understand that you're still exposed to the
risk from those who are not your regular users and how have
sufficient knowledge to circumvent the things you've put in place.
Bus shelters are pretty useless from protecting you from absolutely
all wind, rain and snow, but I'm certainly glad they are there when
I have to stand on the corner waiting for the bus, because they at
least allow you to be sheltered from some of the wind, rain and
snow. That is better than no shelter at all.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc pm*****@pksolutions.com (Peter Miller) wrote in
<gn********************************@4ax.com>: But the impression given here is that
you are telling your clients that the security offered by your DIY
security is 'pretty good' and that is where I disagree with you
strongly.
Seems to me Mike is telling his clients not "pretty good" but "good
enough for the circumstances we've foreseen and within the budget
we've got and within the estimation of potential risk that we
foresee at the present time."
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc pm*****@pksolutions.com (Peter Miller) wrote in
<kq********************************@4ax.com>: On Fri, 14 Nov 2003 14:39:57 +1200, "TC" <a@b.c.d> wrote in
comp.databases.ms-access:
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
This is true.
- and can not acquire full permissions.
And this is false.
Uh, it was pretty clear that TC meant "can not acquire full
permissions via legitimate methods."
As Michka said, it is not at all difficult to break a secured mdb
without any mdw. . . .
We all know this. It's really not relevant to the question of
whether the techniques Mike MacSween is discussing have value for a
particular client with a particular budget, a particular operating
environment and a particular view of the risks.
This whole discussion reminds me of our discussion over unsplitting
an application. There are situations where it is a satisfactory
solution to a particular set of problems. Jet user-level security
is sufficient for certain kinds of scenarios where there is a
certain balance of cost and risk.
These tirades that completely condemn anyone who uses it seem to me
to completely miss the point -- that no application runs in
anything but an environment that is specific to that application.
You can only detemine the appropriate level of security by knowing
a lot about that environment.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Peter Russell wrote:
The danger group are app developers, who are likely to be more interested
in nicking the application design than the data.
MDE would save the code from these, won't it?
Of course, where you are dealing with personal data or otherwise sensitive
data you have to be seen to be taking steps to discourage abuse/misuse/
whatever.
Encrypting the data would (to a degree) take care of that, won't it?
I am naive, I know. There is always someone who can break in. But
chances are not very high they will be interested in my application :-)
Cheers,
Pavel
ru***@127.0.0.1 (Peter Russell) wrote in
news:me**********************@russellscott.btinter net.com: The danger group are app developers, who are likely to be more interested
in nicking the application design than the data.
Why?
--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
David,
On Fri, 14 Nov 2003 21:02:56 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access: On Fri, 14 Nov 2003 14:39:57 +1200, "TC" <a@b.c.d> wrote in
comp.databases.ms-access:
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
This is true.
- and can not acquire full permissions.
And this is false.
Uh, it was pretty clear that TC meant "can not acquire full
permissions via legitimate methods."
And that clarification was necessary because, as we all know, if one
chooses to use illegitimate methods, then full permissions are easily
acquired. But what does the term 'legitimate methods' mean? Your
implication, of course, is that if one is willing to cross the line
and work with the black arts or whatever, then sure, all can be
revealed, but if one sticks to the high road and legitimate use of
Access, TC is correct and full permissions can not be obtained.
But where you're wrong (and TC too if indeed he means what you say he
means) is that 'legitimate methods' can indeed be used to bypass
Access security, without resorting to any black arts. You can use vba
and the methods and objects exposed specifically for security model
manipulation to desecure a file. So I stand by my claim that TC's
statement that full permissions can not be acquired is false, even
when one sticks to 'legitimate methods'.
These tirades that completely condemn anyone who uses it seem to me
to completely miss the point -- that no application runs in
anything but an environment that is specific to that application.
You can only detemine the appropriate level of security by knowing
a lot about that environment.
....or a lot about the problems with a given tool. If you know, for
want of an analogy, that a circular saw has a 5% likelihood of having
the blade come loose when turned on, then you can saw, with great
authority, that it should not be used for cutting wood, regardless of
any specific of what type of wood will be cut, what type of person
will be operating the saw, how long they will be using it for, etc,
etc. Sure, a tradesman using the saw all day every day to cut certain
grades of wood is far more likely to be harmed by the flawed tool than
someone who turns it on and off just once for thirty seconds and cuts
nothing at all, but that is beside the point. The tool is flawed and
should not be used at all.
Now in the case of Access, I'm not at all suggesting it should not be
used at all. Its a fine rad tool. But I am suggesting that anyone
who thinks that Access security provides them with any meaningful
level of security is terribly mistaken.
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
David,
On Fri, 14 Nov 2003 20:45:52 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access: pm*****@pksolutions.com (Peter Miller) wrote in
<gg********************************@4ax.com>:
If you told your client, 'hey, the security I'm building into this
app is pretty weak, but <nod, nod, wink, wink> look at your users
and your security needs - you'll be just fine with weak security'
then I'd have no problem with that.
I've done exactly (well, in so many words) that with every client
for whom I've built an Access application that used Jet user-level
security. My philosophy is that erecting any barrier protects you
from some useful number of attacks, even if not from all. When the
client considers the low level of protection unacceptable, we
discuss the costs of getting higher levels of protection. None of
my clients has ever chosen to go with anything more secure, based
on a cost/benefit analysis that was itself best on a gut-level
estimation of the risks involved.
Then we obviously have no argument on that front.
Your argument is based on the idea that we've mis-estimated the
risk, and thus are under-rating the benefit of switching to a
platform with higher levels of security.
No, not at all. Given what you've said above, I think you've taken
exactly the right approach. Basically, if you tell you clients that
Access security provides very minimal protection, then I endorse that
approach whole-heartedly. But th impression I have from Mike's posts
is that he's promising something better, and that's when I start
wondering how accurate the picture is that he's painting for his
clients. It sounds like it might be a little to rosy to me.
That's a reasonable argument.
But it's a rather different one from the one you appear to be
making.
Huh?
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
David,
On Fri, 14 Nov 2003 20:55:39 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access: But Mike is specifically talking about things that you can do that
erect barriers to prevent mis-use of the application and its data
by the regular users doing their usual tasks.
I think it's reasonable to do most of the things Mike has talked
about, as long as you understand that you're still exposed to the
risk from those who are not your regular users and how have
sufficient knowledge to circumvent the things you've put in place.
Bus shelters are pretty useless from protecting you from absolutely
all wind, rain and snow, but I'm certainly glad they are there when
I have to stand on the corner waiting for the bus, because they at
least allow you to be sheltered from some of the wind, rain and
snow. That is better than no shelter at all.
But of course. I agree 100%.
But what if you suggest that by putting a letter-box outside the bus
shelter, and a bathroom, and make the seats kind of plush and
couch-like, that your bus shelter is starting to look awfully comfy
and somewhat house-like. Do I have a problem with any of these
modifications? Of course not (similarly, Mike should make all the
enhancements to Access security he likes). But if you actually try
and pass off the bus shelter as a house, you're being less than
forthright. Likewise, if Mike tells his clients that his
super-enhanced security model is anything other than a simple
deterrent to unintentional misuse, he is, in my view, being
misleading.
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
On Fri, 14 Nov 2003 20:57:28 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access: Seems to me Mike is telling his clients not "pretty good" but "good
enough for the circumstances we've foreseen and within the budget
we've got and within the estimation of potential risk that we
foresee at the present time."
Really? You really think that the clients will take "good
enough for the circumstances we've foreseen and within the budget
we've got and within the estimation of potential risk that we
foresee at the present time." as being anything less than an
endorsement of the security capabilities of their application? I'd
say that such a statement would very much be taken by the client as
'don't worry about security in this app - it's up to the task'.
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
"David W. Fenton" <dX********@bway.net.invalid> wrote in message I think most people who respond as Michael did are simply misreading
your goal. You're not looking for security. You're looking to erect
as few barriers to the casual users.
Hurrah!! Somebody understands. I'm not speaking a foreign language after
all.
Mike
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.78.. . jw***@nospamtyenet.com (Joan Wild) wrote in
<bp********@enews1.newsguy.com>:
Case in point
http://groups.google.com/groups?hl=e...=UTF-8&selm=3D
907C27.6010206%40noaddress.com
Don't underestimate users' capabilities.
The question assumes:
1. users know that there is such a thing as "Access security."
2. they know that it is crackable.
3. they know that their app uses it and is preventing them from
doing certain things so that they have the motivation to
investigate how to get around it.
The question asked gave them that information.
I agree David.
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:91********************************@4ax.com... But what if you suggest that by putting a letter-box outside the bus
shelter, and a bathroom, and make the seats kind of plush and
couch-like, that your bus shelter is starting to look awfully comfy
and somewhat house-like. Do I have a problem with any of these
modifications? Of course not (similarly, Mike should make all the
enhancements to Access security he likes). But if you actually try
and pass off the bus shelter as a house, you're being less than
forthright. Likewise, if Mike tells his clients that his
super-enhanced security model is anything other than a simple
deterrent to unintentional misuse, he is, in my view, being
misleading.
You're a reasonable man Peter. Do me this courtesy. Read through my posts in
this thread, now, and find me the ones where I am doing anything like what
you say. I just read them quickly myself and couldn't find anything where
I'm claiming that it's possible to make Access security impregnable. You
imply above that that is what I'm saying. Please don't put words in my
mouth.
Yours, Mike MacSween
"Joan Wild" <jw***@nospamtyenet.com> wrote in message
news:bp********@enews1.newsguy.com... Case in point
http://groups.google.com/groups?hl=e...0noaddress.com
Don't underestimate users' capabilities.
That's an interesting link Joan. Apart from the usual sexist implication
('look, even lady secretaries can find Access cracking tools') it would be a
lot more interesting to know what they did to actually try and 'break into'
the databases. Did they succeed? As David points out, there's little proved
when many people will not actually realize that there is such a thing as
Access security that they need to crack.
Yours, Mike MacSween
On Fri, 14 Nov 2003 21:03:36 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access: You're a reasonable man Peter. Do me this courtesy. Read through my posts in
this thread, now, and find me the ones where I am doing anything like what
you say. I just read them quickly myself and couldn't find anything where
I'm claiming that it's possible to make Access security impregnable.
You're right. You said no such thing.
But, unfortunately (for your case), I'm right too. Because I never
claimed you said Access security was impregnable, now, did I? Please
do me the favor of the same re-read. We're not arguing about whether
security is impregnable. We both agree, quite obviously, that it is
not. But you do say security is suitable to the clients needs. I
agree, if and only if, there needs are basically non-existant, and
that all you really want to do is prevent unintentional misuse.
Built-in Access security already does this somewhat. But you are
trying to strengthen it.
Please correct me if I'm wrong, but your posts clearly indicate, to
me, that you are trying to offer a level of security over and above
what is built-in. You said that the common wisdom is that Access
security is hopelessly flawed, but that with some tweaks and
additions, you can make it (hopefully) workable.
You imply above that that is what I'm saying. Please don't put words in my
mouth.
Mike, you too are a reasonable person. I am not at all implying that
you think Access security is, or can be made solid, let alone
impregnable. All I am saying (and its not by implication - I'm quite
clearly saying it outright) is that you indicate Access security can
be made workable, and therein lies our disagreement. I say that it
can not. I say that if Access security meets your security needs,
either you don't have security needs or you're over-estimating what
Access security (and/or your DIY security) can do.
Now I know, you can argue that your client's users are REALLY STUPID
and couldn't fight their way out of a wet paper bag, and while I might
suspect it, I can't say with certainty that you're wrong about them,
but here's my point. Have you made that same point, and stressed it
as strongly, to your client? If so, and they agree, then fine, but if
you're telling them about how neat your enhancements to Access
security are, and me about how stupid their users are, then
something's amiss.
I'm not trying to put words in your mouth. I am trying to stress, and
stress as clearly as possible, that Access security is not just
slightly flawed. It has holes you could drive a bus through. Michka
is telling you likewise. I commend your efforts to improve it. I
started out likewise, and pursued many avenues with certain others in
this ng and elsewhere to see if we couldn't shore up the holes, but in
the end, it became clear that things were just too flawed. I am not
knocking your efforts because I under-estimate you (I don't) but
because I think I have a pretty good understanding of the issues. I
should. I did some consulting work for Microsoft on Access security
and revealing its flaws specifically. I honestly and sincerely
believe that telling clients that Access security (and that which you
can build on your own on top of it) is anything other than terribly
weak and flawed is doing them a disservice.
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
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:gg********************************@4ax.com...
Peter, thanks for you reply Relativity doesn't mean a complete inability to pass judgement - just
that judgements will vary based on perspective. You can indeed say
that Access security is quite poor even with the understanding that
this is relative.
Otherwise, for example, simply changing the suffix from mdb to xyz on
a non-secured database would be, in your view, a security measure that
one could not say was good, bad or anything else. After all, security
is relative, right, and most of the worlds population would not be
able to break into your 'secured' file.
The concept of a 'secured' file is yours, not mine.
Relativity is not just a
numbers game (most of the population would indeed be incapable of
breaking into your suffix-changed file because most of them lack
access to a computer, and even those that have access to a computer,
would lack access to your specific file, and even those with access to
a computer and your file may very well not understand your language,
etc, etc).
Why the need to be so facetious?
Relativity (in ref to security) means that security models
should be judged on their applicability to task.
That's true.
All I can tell you is that you are right. But not 100%. If a 'person' has
access to the FILE they can break into. If. If they have access to the
file.And who is this 'person'. Is it Amanda, our clerical assistant? Or is it
Timothy, our head of department (department being Music)? Or is Anthony,
ourhead of MIS? Have they the ability or knowledge to bypass NT permissions
andAccess security and then 'break in to it'. Do you know? Which 'persons'
didyou have in mind when you said that? And what will they do when they
'breakinto it' (whatever that means - read the data, alter the data?).
Ah yes, we can not talk about security problems in a technology or
architecture without first having in mind a particular user and a
particular malevolent goal. Ridiculous.
Of course it's not ridiculous. I was actually responding to Michael saying
'All a person needs
is access to the FILE (no need to copy, etc.) and they can break in to it.'
I'd say the word 'person' is far too general in this case. My point is that
you often do know who your users are, and make decisions and assumptions
about their capabilities and the importance of the security of the data.
Access security is weak
because it protects against very few types of attacks, and none
effectively. You say people misunderstand your point, but I would
posit that we don't. We understand what you're saying. You're basic
thrust is given a naive enough set of users, Access's weak security
might actually be effective, or better yet, maybe DIY security will do
the trick. Given a very controlled environment, what you say is true,
but such an environment doesn't really exist today. Are you positive
that none of the users know how to use a search engine. Are you
positive that even if they are clueless now, that they will never
learn of the internet? Are you equally positive their kids are just
as clueless? And their friends? And that they do not have any
ulterior motives? And that they never will have any?
No to all of them. What do you expect me to say?
The whole point
of effective (and that doesn't at all mean perfect - just meaningful)
Go on, tell me what meaningful means.
security is that it protects against likely and reasonably possible
attacks/threats. Access security doesn't.
Essentially, what you're saying above is that Michka doesn't know the
user base for your specific example, and so he can't speak with any
authority about the strength or viability of the security system you
will provide.
Michael can say whatever he likes. The user base that an application is
designed for makes a difference to how it's designed. Innit?
You're implying of course, that you do know them.
What do you mean IMPLYING? Of course I know them better than Michka. I've
worked with them every week for 10 years. There's no frigging implications,
it's a racing certainty that I know them, and their computer abilities,
better than Michka.
Are
you going to stipulate that your DIY security will be effective
against Amanda and Timothy (presumably not Anthony)
Why presumably not Anthony? What do you know of his knowledge of Access. In
a 5 minute conversation I had with him it became clear that he knows very
little about it. Of course he's an IT professional so he would learn pretty
quick if he had to. He's not a problem. He's head of MIS, if management tell
him to break into my database, that's his job.
provided their
situation doesn't change, motives remain constant, knowledge doesn't
improve, and that nobody else ever gets hired, etc. etc?
Sure, but the crystal ball's on the blink just now. So I'll design on the
basis of the people, and the sort of future people, I expect to get near
this. And the importance of the data being not nicked (which isn't vital).
Of course you aren't.
Of course I'm not.
My point is that you over-estimate the strength provided by Access
security, and it appears, your own DIY security, and that, despite
your belief to the contrary, I am not over-estimating the capabilities
of your client's current and future users.
If you told your client, 'hey, the security I'm building into this app
is pretty weak, but <nod, nod, wink, wink> look at your users and your
security needs - you'll be just fine with weak security' then I'd have
no problem with that.
Neither do I. But I wouldn't phrase it like that. I'm not damn well saying that it isn't possible to bypass Access security
and/or NT permissions. I'm saying it can be made easy, hard, very hard or
extremely hard FOR MOST PEOPLE.
And I'd agree, except that I'd limit it to saying that Access security
and (not or) NT permissions can make it at best moderately difficult
for the average user to bypass.
Average? Would that be mean, median or mode as a measure of central
tendency? And are you including your computerless world occupants you
mentioned above. Let me know who this 'average user' is and we'll get her to
attempt to 'break into' a few databases.
Yours, Mike MacSween
"David W. Fenton" <dX********@bway.net.invalid> wrote in message It's perfectly reasonable to depend on Jet user-level security and
NT permissions and logging for a certain level of protection
against user exploits, given a certain determination by the
organization that the cost/benefit ration is appropriate for the
level of risk they are willing to be exposed to.
Thank you David. A simple enough point. And just the one I'm trying to make.
Yours, Mike MacSween
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:t0********************************@4ax.com...
On Fri, 14 Nov 2003 21:03:36 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access:
You're a reasonable man Peter. Do me this courtesy. Read through my posts
inthis thread, now, and find me the ones where I am doing anything like
whatyou say. I just read them quickly myself and couldn't find anything where
I'm claiming that it's possible to make Access security impregnable.
You're right. You said no such thing.
But, unfortunately (for your case), I'm right too. Because I never
claimed you said Access security was impregnable, now, did I?
Well that's how I read your plush bus shelter being passed off as house
analogy. Maybe that's the problem with analogies.
The subject line of this thread, started by me, makes it quite clear that
I'm not making 'claims' for Access security. Quite the reverse. That I don't
fully understand it.
So how do we describe the level of security of a computer system? 90%
secure? What does that mean? That out of 100 'average' users 90 won't be
able to bypass security? Average? Given what sort of facilities? How much
time? Maybe tests have been done. Well, you worked for MS on Access
security, perhaps there was some testing along those lines? No doubt you
signed an NDA, but it'd be interesting to know.
There's no security. Which is something like a Windows 95 machine, already
running, with a single shortcut on the desktop to a Word document. And there
might be complete security. Don't know what that is. Some mainframe in a
bunker somewhere I suppose. And somewhere in between there's an Access app.
Can't think of any other way to describe it, really.
What I was interested in was how to 'harden' Access security. And I think it
can be hardened. I expect you think that the most it can be hardened is from
blancmange hardness to creme brulee hardness. I am making no promises to
clients. The spur for this investigation is some development I'm doing as an
employee (a non IT employee) at an academic institution. At the end of last
year various people starting copying mdb files about, putting them on
network shares etc. It became a mess. I'm very very sure that they can't do
that now, except with the help of MIS. Which is acceptable to me, because
that is one of MIS's roles. Over the coming weeks I will make it harder for
people to mess with the database as they have in the past. Hopefully at
least to the point where they ask me. Or at least they have to use tools
which if nothing else, alerts them themselves to the fact that they are
doing something they shouldn't be.
Yours, Mike MacSween
On Fri, 14 Nov 2003 21:58:10 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote in
comp.databases.ms-access: Well that's how I read your plush bus shelter being passed off as house
analogy. Maybe that's the problem with analogies.
Yeah, you've got a point there.
The subject line of this thread, started by me, makes it quite clear that
I'm not making 'claims' for Access security. Quite the reverse. That I don't
fully understand it.
Fair enough. Perhaps I can clarify. You were talking more about DIY
security while I tend to refer to it as Access security + DIY
security. I refer to the combination rather than just DIY because if
done correctly, your efforts should supplement Access security. I
have no problem if you want to talk about just one or the other, but I
thought by talking about both combined I was giving your arguments the
best possible footing. I didn't mean to imply that your concerns were
with Access security solely, but rather with security in Access, which
I presumed would incorporate the best possible features from both
Access security and whatever you could add to it.
So how do we describe the level of security of a computer system? 90%
secure? What does that mean? That out of 100 'average' users 90 won't be
able to bypass security? Average? Given what sort of facilities? How much
time? Maybe tests have been done. Well, you worked for MS on Access
security, perhaps there was some testing along those lines? No doubt you
signed an NDA, but it'd be interesting to know.
Well, the NDA has expired, so no problem there. The real limitation
is in that its hard to have these types of conversations and prove a
point without showing code to remove all doubts, but doing so
inevitably plays into the hands of malevolent folk, which is why
you'll find people like Michka and I arguing vociferously that you
really REALLY need to understand that the model is flawed and not to
be relied upon.
I didn't do user testing. I did software testing. I found many
holes, at many levels, and have been very saddened, without getting
too specific, at how little improvement had been made ever since. I
came to the conclusion that the whole point of my involvement, from
Microsoft's perspective, was to put me under NDA and keep me from
discussing the flaws rather than to actually act on the information
and improve the product. I could be wrong. The people I worked with
seemed nice enough. But the reality is that the work went nowhere
because Access is as easy to break into today as it was when I did the
contract work.
I originally got into this whole field because I had a product to send
out, and I wanted to implement security. I implemented it, and tested
it, and was aghast at the holes. I investigated some more, and found
more problems. I came across some like minded individuals who I
worked with to see if the problems couldn't be resolved (if not by
Msft, then using encryption and add-ins and the like) and after a lot
of effort, came to the realization that there was no hope. In other
words, I didn't come to this issue as a security expert looking at a
what I considered to be a toy consumer product like Access and
denigrating it out of hand. Instead, I came at it as a developer with
a first time security need, and started from the ground up, only to
find at almost every level that the security was completely
unreliable.
What I was interested in was how to 'harden' Access security. And I think it
can be hardened. I expect you think that the most it can be hardened is from
blancmange hardness to creme brulee hardness.
Precisely.
I am making no promises to
clients. The spur for this investigation is some development I'm doing as an
employee (a non IT employee) at an academic institution. At the end of last
year various people starting copying mdb files about, putting them on
network shares etc. It became a mess. I'm very very sure that they can't do
that now, except with the help of MIS. Which is acceptable to me, because
that is one of MIS's roles. Over the coming weeks I will make it harder for
people to mess with the database as they have in the past. Hopefully at
least to the point where they ask me. Or at least they have to use tools
which if nothing else, alerts them themselves to the fact that they are
doing something they shouldn't be.
Fair enough, except remember that no tools need to be installed or
run. A few lines of vba code run within Access will do the trick.
And your logs would show nothing untoward.
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
Obscurity is not security, and it is irresponsible and unrealistic to assume
this is good enough, for anyone.
Please let me know what companies you do this for who find it an acceptable
practice, so I can be sure to never trust them with any credit card
information?
--
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" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. . "David W. Fenton" <dX********@bway.net.invalid> wrote in message
I think most people who respond as Michael did are simply misreading
your goal. You're not looking for security. You're looking to erect
as few barriers to the casual users.
Hurrah!! Somebody understands. I'm not speaking a foreign language after
all.
Mike
"Peter Miller" <pm*****@pksolutions.com> wrote... While Michka may have turned this into a lucrative traveling show
(kudos Michka - wish I'd thought of that!), it can be proven in a much
more direct fashion.
It grew out of a simple presentation I did for some Access user groups -- a
few people sent reps from their companies who then came back pleading for
more info. It never would have occurred to me otherwise. :-)
Michka and I can do all the
desecuring examples we like and people can still say, 'well, ok, but
you guys know something special'.
I wish people would realize how untrue this supposition is....
The only way to *prove* how trivial
security is to bypass (without mdw's, special tools, or any prior
knowledge of a secured mdb's contents) is to publish the code to do
so. I don't want to do this because it has obvious possibilities for
abuse. Michka could do likewise, of course (and has, to his credit,
in one special case).
I was essentially doing just that in these sessions, but everyone who has
access to the materials is required to sign an agreement to never use the
techniques. :-)
It would be far better if people would accept
that Access/Jet security is very weak indeed, rather than thinking
that it's just a matter of the right tweaking, and effective security
can be provided for with Jet. Part of the problem, is, of course,
that jet is a file-server based rdbms, and not a service, and as such,
has inherent weaknesses that can not be overcome as do other similarly
architected systems, but part of the problem is also the weakness of
the implementation. Taken together, they spell doom for any
meaningful level of security in Jet. This really can not be over
stressed.
If only people would listen?
--
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.
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.78.. . pm*****@pksolutions.com (Peter Miller) wrote in
<kq********************************@4ax.com>:
On Fri, 14 Nov 2003 14:39:57 +1200, "TC" <a@b.c.d> wrote in
comp.databases.ms-access:
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
This is true.
- and can not acquire full permissions.
And this is false.
Uh, it was pretty clear that TC meant "can not acquire full
permissions via legitimate methods."
Yes, that is exactly what I meant. I'm well aware that it is possible to
descure any secured database (without a workgroup file) - because I can do
it myself :-)
TC
As Michka said, it is not at all difficult to break a secured mdb
without any mdw. . . .
We all know this. It's really not relevant to the question of
whether the techniques Mike MacSween is discussing have value for a
particular client with a particular budget, a particular operating
environment and a particular view of the risks.
This whole discussion reminds me of our discussion over unsplitting
an application. There are situations where it is a satisfactory
solution to a particular set of problems. Jet user-level security
is sufficient for certain kinds of scenarios where there is a
certain balance of cost and risk.
These tirades that completely condemn anyone who uses it seem to me
to completely miss the point -- that no application runs in
anything but an environment that is specific to that application.
You can only detemine the appropriate level of security by knowing
a lot about that environment.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Hi MK
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com...
(snip) There is at least one method that DOES exist in the wild that does not
require an MDW.
Ok, that's news to me.
The myth of secure MDBs is just that -- a myth.
I see from PM's post that it is allegedly possible to desecure a db using
standard methods & properties. That also is news to me! Clearly, my thinking
cap has come loose over time! I can do the desecuring thing myself, but only
the hard way (decrypting the db then amending the values stored therein).
Cheers,
TC
"Michael (michka) Kaplan [MS]" <mi*****@online.microsoft.com> wrote in
message news:3f********@news.microsoft.com... Obscurity is not security, and it is irresponsible and unrealistic to
assume this is good enough, for anyone.
Well, Access security must be 'good enough' for somebody. Like the people
who use it. Like David and the 1000s of other developers who apply the
built-in security, and NT permissions, and maybe a few ideas of their own.
Have you never applied Access security when you've developed applications?
It's a genuine question. You say Access security isn't worth anything so
perhaps you never bother using it?
Sure, you might think that 'Access security' is an oxymoron. Talk about what
constitutes 'security' till you're blue in the face. We all know what we are
really talking about here. And despite mistaken impressions to the contrary
I have never put forward the idea that Access security can be total.
Please let me know what companies you do this for who find it an
acceptable practice, so I can be sure to never trust them with any credit card
information?
Oh, Chase Manhatten, Amazon, ebay. Of course even I know that an app
developed using Access wouldn't be secure enough to store cc details. Don't
be so damned facile.
Now take the cotton wool out of your ears. What I am NOT saying is that
Access security can be made complete. Did you hear? But the predisposition
amongst some here, including you I think, is to see a thread about Access
security and to think - 'oh, here's some poor sap who thinks Access security
can be made strong, better tell him he's wrong'. Obviously many have tried
to do make Access security strong, including Peter Miller it seems, and
maybe you too. And some have posted their efforts, only to find them proved
inadequate.
In this particular case:
1. Only those people who know about the database even know it exists. They
may or may not tell their friends/relatives and so on.
2. At the moment the people who know about the database already have some
access to it.
3. They would need a desire to change the data without authority.
4. Theft of the data would not bring down the organisation. It may
constitute a breach of the data protection act, especially if it were widely
published.
5. Unauthorised alteration of the existing data is more of a concern. It's a
database for recording student marks. Students are the ones who might want
to alter marks. They have to get past NT security first. It's on a domain
they don't have access to, in the ordinary course of events. Of course,
people leave machines on etc. etc. We know that NT security can be
circumvented in various ways, often 'socially'. That is beyond my control.
And of course the same caveat applies to all the college's data.
6. The academic process involves the discussion of each student's overall
year mark, then degree award, at a board of examiners. Usually 10-20 members
of the academic staff, most of whom will know the students' work fairly
well. Borderline students are always discussed. A student who had
significantly higher grades than was expected would be noticed, I think. The
parts of the course which contribute to the class of degree contain only 7
modules. Some of those modules might only contain 1 or 2 assignments. There
is a high probability that the member of staff who marked those assignments
will be present and would remember that actually Jo Soap didn't get 80 for
that piece of work, but 55. And the marks are always recorded in paper form
first, and that list of marks is present at exam board. That brief outline
of how the system is used is why I don't think that you have enough
information to comment on whether Access security (and anything else I might
use) is 'good enough' for me. You don't know the context in which the
application is used. I do. No doubt there are plenty of 'ah, but what ifs'
you have ready for me. I'd be interested to hear them.
7. I will present a precis of this thread to the management of the college,
incorporating a summation of your, Peter's and others' comments. At that
point my professional duty is done. The college management can then make the
decision whether to abandon computerise record keeping, move to a database
server system, or continue with what I'm developing for them.
Yours, Mike MacSween
Sorry Peter and Michael
I realized that the initial post did talk about my 'clients'.
Let me explain. The spur for this thread was my attempts to apply the
security 'techniques' (or non-techniques!) at one place to clients at
another place. The relationship at place (a) is not really client/developer.
I'm a member of that academic staff. You might call that client/developer,
that's a moot point. But the techniques I'm using/trying out there I've
started to apply to the people at place (b) where there is a
client/developer relationship. So because we were discussing techniques I'm
using at place (a), so far, that's the situation I had in mind when I was
talking about the 'user base' and so on. Though in fact the user base at
place (b) would have even less reason to maliciously alter data, and the
data is even less valuable to outsiders.
Sorry to (unintentionally) mislead you.
Mike MacSween
Lyle Fairfield previously wrote: ru***@127.0.0.1 (Peter Russell) wrote in
news:me**********************@russellscott.btinter net.com:
The danger group are app developers, who are likely to be more
interested in nicking the application design than the data.
Why?
--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Because they can!
Peter Russell This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: craig |
last post by:
I am working on my first .NET development project that involves custom
role-based security per the project requirements. This lead to a general
design issue this week that really caused us some...
|
by: Mike MacSween |
last post by:
Further to 'Security - more complex than I thought'
Has anybody ever seen any studies? Or anecdotal evidence? Done any studies
themselves? Done any lab testing - you know - 10 users asked to get...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: DJRhino |
last post by:
Private Sub CboDrawingID_BeforeUpdate(Cancel As Integer)
If = 310029923 Or 310030138 Or 310030152 Or 310030346 Or 310030348 Or _
310030356 Or 310030359 Or 310030362 Or...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
| |
