Re: Advance Security Issue Part II
- From: "theriaup" <theriaup@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 25 Jun 2005 01:29:01 -0700
Doh! Thwarted by Microsoft again! Thanks for you very complete answer
though... I'll have to test out your suggestions. Although even with that
security problem, I think I'll end up with a pretty secure database. Or at
least as secure as it can be without having an armed guard standing by...
"TC" wrote:
>
> theriaup wrote:
>
> > Okay, I've got the dual-mdw thing all straight, now I have a permissions
> > question.
>
> Permission granted!
>
>
> > In my master mdw, DEV.MDW, I have the SuperUser who owns all objects and has
> > all permissions. SuperUser has created a table called SYSTABLE. He has also
> > created a Snapshot query to read that table. The DBUSERS group has no
> > permission on the table, but READ permission on the query (which is set to
> > use the owner's access).
>
> Looks good so far.
>
>
>
> > When I create the user DataUser in DEV.MDW, and add him to the DBUSERS
> > group, all is fine. He can't touch the table, or view the design of the
> > query, but can run the query and view the data.
>
> Still looks good - but I have this strange feeling that something is
> about to go wrong! :-)
>
>
>
> > Now when I create the user SiteUser in the second mdw - USER.MDW, and add
> > SiteUser to the DBUSERS group (which has been created with the same PID as
> > DBUSERS in DEV.MDW), he has no access to the query at all.
>
> I'm not surprised! (Um, actually, I was: until I read your next
> paragraph!)
>
>
>
> > Is this because SuperUser doesn't exist in USER.MDW (thereby nullifying the
> > effects of the owner access option)? Or have I just missed something?
>
> No, you got it spot-on. That is the cause of the problem. But it's not
> because the effects of the WITH OWNER ACCESS (WOA, aka RWOP) option are
> being "nullified". It's quite the opposite: the effects of that option
> are exactly what they should be in that circumstance.
>
> You've told Jet to execute the query with the permissions of a user who
> does not exist in the current workgroup file. So, Jet does not know
> /what/ permssions to use, so it can not afford to run the query at all.
>
>
>
> > I was thinking of creating another user in both workgroup files that has
> > read permissions on the table and using him to create the query (that way
> > he'll own the query and can pass permissions on through the owner access
> > option).
>
> Yes, I believe that is exactly what you'll have to do. If anyone else
> can think of a better way, chime in here!
>
>
>
> > That creates a potential security hole though (direct access to the
> > tables, which I'm trying to avoid), since somebody could crack that password.
>
> Yes. The ability to reverse-engineer the passwords from the workgroup
> file, is very unfortunate. It is /not/, as many people mistakenly say,
> due to the fact that the workgroup file is freely available for people
> to play with. It is instead due to a simple, "schoolboy howler" mistake
> in how the passwords are encrypted. I've submitted a suggestion on how
> to eliminate this, with what I believe would be a 2 line fix to the Jet
> sourcecode! Whether that will ever be done is, of course, a matter for
> conjecture by us mere mortals.
>
> Here's what I'd do. Create the new user, and give him (via VBA code) a
> password like "s3crrrxx3t", where the two x's represent the hex
> character for BACKSPACE - 0x08, from memory. Then, when the user runs a
> cracking utility to display the passwords, the utility - unless it is
> /very/ smart - will send the following character sequence to the
> screen: s 3 c r r r BACKSPACE BACKSPACE 3 t. So the user will
> see: "s3cr3t". That sure looks like a secret password!! But it will not
> work, from the login box, or via VBA, because it actually isn't the
> password, at all!
>
> I think that would deter all but the most determined & technically
> sophisticted users. You could throw some ENTERs (0x0D) and LINEFEEDs
> (0x0A) into the mix, as well, if you wanted. You could easily see how
> your choice, would look on the screen:
>
> debug.print "s3crrr"; chr$(8); chr$(8); "3t"
>
> Remember: 1% of effort will deter 99% of hacking users. But *no amount*
> of extra effort, will deter the remaining 1%.
>
> HTH,
> TC
>
>
.
- References:
- Advance Security Issue Part II
- From: theriaup
- Re: Advance Security Issue Part II
- From: TC
- Advance Security Issue Part II
- Prev by Date: Re: input access 2 people at same time
- Next by Date: Re: Advance Security Issue Part II
- Previous by thread: Re: Advance Security Issue Part II
- Next by thread: Re: Advance Security Issue Part II
- Index(es):
Relevant Pages
|
