Access security hole?
Neil W
"password" at the prompt and I am in.
Now another person starts a second instance of MSAccess. Since
Northwind.mdb is already opened in one instance of Access, they can connect
to northwind.mdb from the second instance without having to know or enter
the password!
Is there any way of preventing this?
Thanks.
Armen Stein
>Now another person starts a second instance of MSAccess. Since
>Northwind.mdb is already opened in one instance of Access, they can connect
>to northwind.mdb from the second instance without having to know or enter
>the password!
Well, a properly designed Access application would be split, with the
front-end (FE) on each user's PC and the back-end (BE) on a network
share. In that case, each user would need to specify the password to
open their own copy of the FE. Can you be more specific about your
scenario?
Armen Stein
Microsoft Access MVP
www.JStreetTech.com
david
Still, it's not a big problem is it? It only allows another
person to open another copy on YOUR computer,
using YOUR session, while YOU have a copy open.
And if they are doing that, why not just use the copy
you already have open?
This exploit only runs on YOUR computer, while YOU
have the database open, and a key logger would be a
much more general and more standard way to do that.
(david)
"Neil W" <ne...@netlib.com> wrote in message
news:e3ER0EX...@TK2MSFTNGP02.phx.gbl...
Neil W
I guess the question is, is there a way to stop another program using a
GetObject from attaching the the Access database? Can RevokeActiveObject be
used for that?
Thanks.
"Armen Stein" <Armen...@removethisgmail.com> wrote in message
news:l8set59e5ahgsmjrc...@4ax.com...
Armen Stein
>I guess the question is, is there a way to stop another program using a
>GetObject from attaching the the Access database? Can RevokeActiveObject be
>used for that?
Hi Neil,
I see there are no other responses. Sorry, but I don't know enough
about those objects to help you. Hopefully someone else will weigh
in.
Banana
> Thanks for the reply.
>
> I guess the question is, is there a way to stop another program using a
> GetObject from attaching the the Access database? Can RevokeActiveObject be
> used for that?
>
> Thanks.
When an instance of Access.Application is automated, two property will
be different: UserControl and Visible both will be set to false. On your
start up form's Open event, you could do this:
If Not Application.UserControl Then
Application.Quit
End If
This will effectively prevent any automation of this particular database
file. I imagine when used in conjecture with disabling Shift key bypass
(which is easily googable) and converting it into a *DE file, would be
quite frustrating for script kiddies trying to circumvent the expected
design. I wouldn't go as far as saying it'd be bulletproof - nothing is
ever bulletproof - and should remind that in area of securing, it's more
easier to fool oneself into thinking it's secured than it is actually
secure. Also remember that it's cheaper to use a $5 wrench than to build
a million-dollar cluster to crack a strong encryption key.
I should also note that your revised question is somehow different from
first question. The way I'm reading your first question is more about
ensuring that other instances can't access the databases that's been
opened and validated by Access prior.
I am aware of a hole where one could validate the connection in one
application, close the application within the Access then open a new
blank database with same credentials still available and this hole is
easily fixed by always forcing the first application to quit the Access
itself when last form closes.
However, I just tested and could not reproduce the case where one could
have the same access to the prior-validated credentials in a second
running instance of Access. Maybe it'd help if you listed the exact
steps of how you got your 2nd instance of Access to have the
prior-validated credentials.