By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,504 Members | 1,583 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,504 IT Pros & Developers. It's quick & easy.

User/Group Security -- Just How Bad Is It?

P: n/a
TC
In the past I always regarded user/group security as fairly tight. It
is tricky to implement, but once implemented properly, it can't be
cracked except through a dedicated effort.

Recently, however, I saw something which greatly lowered my opinion of
user/group security. I sent a secured database to a colleague. I forgot
to send him the workgroup file, but that didn't slow him down at all.
The next day, he sent me the work I had requested and, as an aside,
mentioned that he built his own version of the workgroup file -- then
he listed every user/PID combination used in the app. In other words,
he had completely cracked the security. I asked him how he did it, and
he said he used a tool downloaded from the internet. We happened to be
using Access 2000, but he says it works just as well with Access 2003.

Based on that experience, Access security now looks extremely weak to
me. Before I reach that conclusion, however, I want to post on the
newgroup for a reality check. Did I make some amateur mistake when
securing the application? (i.e. "Duh! If you don't check the woo-woo
box on the fizziwig form, of course everybody can see your user/PID
data!") Or is user/group security truly weak, and I'm just the last to
know? (i.e. "You didn't know user/group security was worthless? Have
you been living in a cave?")

To put my concerns in the form of a specific question: Is Access
security really so weak that a properly secured Access application can
be completely cracked in less than a minute using software downloaded
from the internet?

It would be good to know.
-TC

Jun 5 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a
The obvious first question is "Did you remove ALL permission from the Admin
user before sending the app out?" If you don't do this, your database is
not secure, period.
Jun 5 '06 #2

P: n/a
TC, the answer to your question is basically, Yes.

I understand that Access 2007 won't bother with security in the new accdb
format.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"TC" <go*********@yahoo.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...
In the past I always regarded user/group security as fairly tight. It
is tricky to implement, but once implemented properly, it can't be
cracked except through a dedicated effort.

Recently, however, I saw something which greatly lowered my opinion of
user/group security. I sent a secured database to a colleague. I forgot
to send him the workgroup file, but that didn't slow him down at all.
The next day, he sent me the work I had requested and, as an aside,
mentioned that he built his own version of the workgroup file -- then
he listed every user/PID combination used in the app. In other words,
he had completely cracked the security. I asked him how he did it, and
he said he used a tool downloaded from the internet. We happened to be
using Access 2000, but he says it works just as well with Access 2003.

Based on that experience, Access security now looks extremely weak to
me. Before I reach that conclusion, however, I want to post on the
newgroup for a reality check. Did I make some amateur mistake when
securing the application? (i.e. "Duh! If you don't check the woo-woo
box on the fizziwig form, of course everybody can see your user/PID
data!") Or is user/group security truly weak, and I'm just the last to
know? (i.e. "You didn't know user/group security was worthless? Have
you been living in a cave?")

To put my concerns in the form of a specific question: Is Access
security really so weak that a properly secured Access application can
be completely cracked in less than a minute using software downloaded
from the internet?

It would be good to know.
-TC

Jun 5 '06 #3

P: n/a
By the way, I"m certainly curious to know the name of the software you used
to crack access security.

If you're talking about a database password, that was never considered very
strong, ever. It was for keeping casual users from making mischief
accidentally, in my opinion.

If you're talking genuine Access user/group security, I'm very interested in
the name of that software.
Jun 5 '06 #4

P: n/a
Allen Browne wrote:
TC, the answer to your question is basically, Yes.

I understand that Access 2007 won't bother with security in the new accdb
format.

In a multi-user LAN environment, I like to use the Operating System
security for who has access to the application. That is pretty secure.
Then my Access security is to limit who can see and do what, among the
authorized users.

But yes one of the authorized users can get password cracking software.
In a company there are usually "administrative sanctions" than can
be brought to bear on people accessing data/information they are not
authorized to access.

Also, last time I looked, I did not find any free Access cracking
software. If still the case, the fee for such cracking software might
be a minor deterrant.

Bob
Jun 5 '06 #5

P: n/a
TC
Allen,

Thanks for the direct answer.

I would be very disappointed if the security features are discontinued
in Access 2007. To me, user/group security would be a very good system,
if only it worked. Let's hope they fix it instead of abandoning it.

-TC
Allen Browne wrote:
TC, the answer to your question is basically, Yes.

I understand that Access 2007 won't bother with security in the new accdb
format.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.


Jun 5 '06 #6

P: n/a
TC
Bob,

It looks like I need a new approach to security. I think I'll start
with the one you recommend.

It sounds like you use a dual log-in system. When they boot the
computer, users log-in to the operating system. When they start the
app, they log-in to the application. The second log-in seems
inefficient to me. If you are relying on the operating system security
anyway, why not use the OS account to govern the behavior of the app
instead of maintaining a redundant workgroup account?

-TC
Bob Alston wrote:
In a multi-user LAN environment, I like to use the Operating System
security for who has access to the application. That is pretty secure.
Then my Access security is to limit who can see and do what, among the
authorized users.

But yes one of the authorized users can get password cracking software.
In a company there are usually "administrative sanctions" than can
be brought to bear on people accessing data/information they are not
authorized to access.

Also, last time I looked, I did not find any free Access cracking
software. If still the case, the fee for such cracking software might
be a minor deterrant.

Bob


Jun 5 '06 #7

P: n/a
"TC" <go*********@yahoo.com> wrote in
news:11**********************@u72g2000cwu.googlegr oups.com:
It sounds like you use a dual log-in system. When they boot the
computer, users log-in to the operating system. When they start
the app, they log-in to the application. The second log-in seems
inefficient to me. If you are relying on the operating system
security anyway, why not use the OS account to govern the behavior
of the app instead of maintaining a redundant workgroup account?


I would love to do this, but have not yet found explanations of the
API to Active Directory that makes any sense to me. I'd be delighted
to use NT user group membership to control access in my Access apps.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jun 5 '06 #8

P: n/a
David W. Fenton wrote:
"TC" <go*********@yahoo.com> wrote in
news:11**********************@u72g2000cwu.googlegr oups.com:

It sounds like you use a dual log-in system. When they boot the
computer, users log-in to the operating system. When they start
the app, they log-in to the application. The second log-in seems
inefficient to me. If you are relying on the operating system
security anyway, why not use the OS account to govern the behavior
of the app instead of maintaining a redundant workgroup account?

I would love to do this, but have not yet found explanations of the
API to Active Directory that makes any sense to me. I'd be delighted
to use NT user group membership to control access in my Access apps.

If you are replying to my post, yes, I do use both the OS security to
control access to the db. Then Access grabs the user ID from the OS and
establishes access privileges based on that ID. No second logon required.

Bob
Jun 5 '06 #9

P: n/a
However, I did find warez cracks for the commercial cracking software.

(david)
"Bob Alston" <bo********@yahoo.com> wrote in message
news:Er*************@fe03.lga...
Allen Browne wrote:
TC, the answer to your question is basically, Yes.

I understand that Access 2007 won't bother with security in the new accdb
format.

In a multi-user LAN environment, I like to use the Operating System
security for who has access to the application. That is pretty secure.
Then my Access security is to limit who can see and do what, among the
authorized users.

But yes one of the authorized users can get password cracking software. In
a company there are usually "administrative sanctions" than can be brought
to bear on people accessing data/information they are not authorized to
access.

Also, last time I looked, I did not find any free Access cracking
software. If still the case, the fee for such cracking software might be
a minor deterrant.

Bob


However, I did find cracks for the commercial cracking software.

(david)

Jun 6 '06 #10

P: n/a
Bob Alston <bo********@yahoo.com> wrote in
news:pD***************@fe03.lga:
David W. Fenton wrote:
"TC" <go*********@yahoo.com> wrote in
news:11**********************@u72g2000cwu.googlegr oups.com:
It sounds like you use a dual log-in system. When they boot the
computer, users log-in to the operating system. When they start
the app, they log-in to the application. The second log-in seems
inefficient to me. If you are relying on the operating system
security anyway, why not use the OS account to govern the
behavior of the app instead of maintaining a redundant workgroup
account?


I would love to do this, but have not yet found explanations of
the API to Active Directory that makes any sense to me. I'd be
delighted to use NT user group membership to control access in my
Access apps.

If you are replying to my post, yes, I do use both the OS security
to control access to the db. Then Access grabs the user ID from
the OS and establishes access privileges based on that ID. No
second logon required.


I already know how to do that. What I don't know how to do is to get
Active Directory group membership so that I can use that to define
who is in which groups.

I mostly don't secure apps with Jet user-level security, but I use
the groups to control who can do what, as group membership is very
easy to determine.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jun 6 '06 #11

P: n/a
David W. Fenton wrote:
I already know how to do that. What I don't know how to do is to get
Active Directory group membership so that I can use that to define
who is in which groups.

I mostly don't secure apps with Jet user-level security, but I use
the groups to control who can do what, as group membership is very
easy to determine.


Might be useful, but in many cases Active Directory Group memberships and
Who-Can-Do-What in an app are not going to correlate anyway. I know it seldom
would with my apps.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Jun 6 '06 #12

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:GQ*******************@newssvr13.news.prodigy. com:
David W. Fenton wrote:
I already know how to do that. What I don't know how to do is to
get Active Directory group membership so that I can use that to
define who is in which groups.

I mostly don't secure apps with Jet user-level security, but I
use the groups to control who can do what, as group membership is
very easy to determine.


Might be useful, but in many cases Active Directory Group
memberships and Who-Can-Do-What in an app are not going to
correlate anyway. I know it seldom would with my apps.


Uh, my point is that if I could use AD group membership, then we'd
transfer the group membership from Jet user-level security to AD
group membership. I have at least one sysadmin who would vastly
prefer one central user definition level, rather than having to
maintain two. And I can't blame him.

And the need would also be for using AD organizational units, not
just group membership, since that (if used as intended) could tell
you, for instance, which location a user is associated with.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jun 7 '06 #13

P: n/a
Using ADO, you can query AD like a table, so you can,
if you want to, build your own permission matrix based
on AD.

Of course, for anything other than the simplest stuff,
that would be a massive exercise.

(david)
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:GQ*******************@newssvr13.news.prodigy. com:
David W. Fenton wrote:
I already know how to do that. What I don't know how to do is to
get Active Directory group membership so that I can use that to
define who is in which groups.

I mostly don't secure apps with Jet user-level security, but I
use the groups to control who can do what, as group membership is
very easy to determine.


Might be useful, but in many cases Active Directory Group
memberships and Who-Can-Do-What in an app are not going to
correlate anyway. I know it seldom would with my apps.


Uh, my point is that if I could use AD group membership, then we'd
transfer the group membership from Jet user-level security to AD
group membership. I have at least one sysadmin who would vastly
prefer one central user definition level, rather than having to
maintain two. And I can't blame him.

And the need would also be for using AD organizational units, not
just group membership, since that (if used as intended) could tell
you, for instance, which location a user is associated with.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Jun 7 '06 #14

P: n/a
Bri

david epsom dot com dot au wrote:
Using ADO, you can query AD like a table, so you can,
if you want to, build your own permission matrix based
on AD.

Of course, for anything other than the simplest stuff,
that would be a massive exercise.

(david)


Could you elaborate on that? This sounds like an interesting possibility.

Thanks

--
Bri

Jun 8 '06 #15

P: n/a
using ADO, you can query against active directory, using LDAP
dialect, where the filter looks like an LDAP filter, or using SQL:

SELECT ADsPath, cn FROM 'LDAP://OU=Sales,DC=Fabrikam,DC=COM'
WHERE objectCategory='person' AND objectClass ='user'
http://msdn.microsoft.com/library/en...bjects_ado.asp

http://msdn.microsoft.com/library/en...ap_dialect.asp

I note that one of those examples uses "ADsDSOObject" as the provider,
the other uses "Active Directory Provider".

I am not familiar with either provider: for all I know they may be
two names of the same provider.

(david)
"Bri" <no*@here.com> wrote in message
news:t7Mhg.255970$WI1.111550@pd7tw2no...

david epsom dot com dot au wrote:
Using ADO, you can query AD like a table, so you can,
if you want to, build your own permission matrix based
on AD.

Of course, for anything other than the simplest stuff,
that would be a massive exercise.

(david)


Could you elaborate on that? This sounds like an interesting possibility.

Thanks

--
Bri

Jun 8 '06 #16

P: n/a
Bri <no*@here.com> wrote in news:t7Mhg.255970$WI1.111550@pd7tw2no:
david epsom dot com dot au wrote:
Using ADO, you can query AD like a table, so you can,
if you want to, build your own permission matrix based
on AD.

Of course, for anything other than the simplest stuff,
that would be a massive exercise.

(david)


Could you elaborate on that? This sounds like an interesting
possibility.


Yes, I would be interested in that, too. Just browsing references, I
did encounter an ActiveDS type library that really does seem to
provide an interface into AD, but it's quite complex (seems to have
a great deal of redundancy).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jun 8 '06 #17

P: n/a
Bri


david epsom dot com dot au wrote:
using ADO, you can query against active directory, using LDAP
dialect, where the filter looks like an LDAP filter, or using SQL:

SELECT ADsPath, cn FROM 'LDAP://OU=Sales,DC=Fabrikam,DC=COM'
WHERE objectCategory='person' AND objectClass ='user'
http://msdn.microsoft.com/library/en...bjects_ado.asp

http://msdn.microsoft.com/library/en...ap_dialect.asp

I note that one of those examples uses "ADsDSOObject" as the provider,
the other uses "Active Directory Provider".

I am not familiar with either provider: for all I know they may be
two names of the same provider.

(david)


Nothing against you personally, I know you are just the messenger,but
these links are terrible. They are inconsistant in their examples
(variable names change between samples) and none of them actually work.
At least I couldn't get anything but errors out of them. I'll do some
more reading on this, but I'm not holding my breath. Thanks for the lead
in any case.

--
Bri

Jun 8 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.