Help! Stop the shift from unlocking database

[Alicia]

I found a way to disable the shift key when opening the
database. Unfortunately if the shift key is not let go
of, then the menu can be accessed and all the startup
options can be changed. So the method I used to disable
the shift key is worthless. Is there (maybe on my form
load) to tell the keyboard to let go of the shift key
even if the (pain in the butt)-user still has it pressed
down?

 

[Wayne Morgan]

In Tools|Startup... uncheck "Allow Access special keys". However, make a
backup of your database first. This will also disable F11 to bring up the
database window, Alt+F11 for the Code window, etc.

 

[Alicia]

I did uncheck the "Allow Access special keys", but I
noticed that someone was unlocking the database anyway.
I started trying to see if I could unlock it and it turns
out that if you press the shift key and just never let it
unpress then you can go back into the tools|startup and
check the boxes all back on.

What I have figured out so far, is that the Form_Load and
Form_Activate events are running even though I keep the
shift key pressed down. So if some how I can tell the
keyboard to release the shift key at least for a second,
then maybe the menu will disappear and the user won't be
able to get to the startup options.

Am I making any sence here?
Do you know how to "UNsend" keys??? or release keys?
I can't even remember how to sendkeys and sending keys
doesn't work on some newer computers so maybe I need to
go a different route.

 

[Guest]

I have done the AllowBypassKey property to False thing
and everything. I even made it so that it can't be set
back to true. Aparently none of this matters, you can
still get in the database.

I'm going to try changing the default menu to a custom
menu. I will let you know if it works.

Please if anyone has an idea or solutions let me know.

Thank you and thank you in advance.

 

[Albert D. Kallal]

I am not experience your problem.

Try downloading the following code example here:
http://www.attcanada.net/~kallal.msn/msaccess/DownLoad.htm
(grab the 3rd one, with the ms-access interface "hidden").

Then, go here, and grab my shift key modifier code:
http://www.attcanada.net/~kallal.msn/msaccess/msaccess.html

Ok, run the shift key code, browse to the other example you downloaded.
disable the shift key.

Now exit.

Now, try running the sample..and see if the shift key can get you inside.
You can't.

So, take a look at the tools->startup settings I used.

I ONLY needed the tools->startup to lock everything up..

 

[Guest]

I'm going to try that out, so I can use it for other
things.

I did find that I could create a custom menu and set it
to be the default menu. Then the user can't access the
tools menu anymore even with the shift key held down.

Thank you for your help!!

 

[Jeff Conrad]

I believe I can re-create your situation and yes, the solution is to create a custom menu bar.

Steps to re-produce:
1. Create a blank database.
2. Create one new form called Form1.
3. Set that form as the Startup and uncheck the options for showing the Database Window and Allow
Bypass Keys.
4. Close database.
5. Use Albert's utility to disable the Shift key bypass.
6. Open database while holding Shift Key down. The form opens and Database Window is hidden.
7. Let go of Shift key or keep holding (it doesn't matter).
8. Go to File | Close which will close the database.
9. Go to File | and then choose this database from the first one in the MRU list.
10. Doesn't matter if you hold shift key down or not, but the database opens again with no form
showing and the Database Window showing!

This test was on an Access 97 machine.

So the solution is to create a customized menu bar that does not have those File | Close and other
built-in Access options. I thought I remember seeing a KB article about this sometime, but I could
be wrong.

 

[RedStar]

I'm a bit confused by this...
i'm not using any shift modifier code
but have the DB invisible and the special keys off...
if i RIGHT-CLICK on the app and select open...
the app opens into the database window and all is exposed.
(normally running app..hides DB window and auto loads my form that covers
everything else

is this what you guys are talking about or something different?

 

[RedStar]

edit: SHIFT-rightclick then select open from menu.

 

[Rick Brandt]

I'm a bit confused by this...
i'm not using any shift modifier code
but have the DB invisible and the special keys off...
if i RIGHT-CLICK on the app and select open...
the app opens into the database window and all is exposed.
(normally running app..hides DB window and auto loads my form that covers
everything else

There is no menu option for disabling the shift key. Disabling "special keys"
in the start menu is a separate issue. You can execute code to disable the
"ByPassKey" which is what disables the use of the shift key. Either you have
executed this code in this particular file or you have not. If you have then
how long they hold the shift is irrelevant.

In addition, if you haven't implemented User-Level Security, then any file where
you have disabled the Shift Key can have similar code run against it that will
re-enable it by anyone who knows how to do this. With User-Level Security
implemented you can at least restrict who can run this code to members who have
administrative authority.

 

[RedStar]

ok i've done a bit of experimenting with this.
and it works as advertised.

BUT, how do you now stop anyone from using your shift disabler/enabler
program from exposing the database guts again?

TIA

 

[RedStar]

ah..so you mean that shift code i just asked about up above ...can't be
stopped unless user level security is activated.

But my problem is ..this program will eventually be on lots of other
computer systems. I have found that such user-level protection breaks down
when you simply move the file to
another computer.

(or is it the case that the new menu/shift disable and user security
combined will keep program safe on other systems ...from being tampered
with?)

DOne alot of Access but i've never been concerned with security before.

So what do you have to do to make sure the application stays closed once its
distrubuted?

TIA
RS*

 

[Rick Brandt]

ah..so you mean that shift code i just asked about up above ...can't be
stopped unless user level security is activated.

But my problem is ..this program will eventually be on lots of other
computer systems. I have found that such user-level protection breaks down
when you simply move the file to
another computer.

That's only true when you apply security incorrectly (like most do).

DOne alot of Access but i've never been concerned with security before.

So what do you have to do to make sure the application stays closed once its
distrubuted?

If you're trying to protect your code use an MDE. If the Data needs protecting
beyond what Access security provides then you need to use a server-based data
engine.

 

[Jeff Conrad]

As Rick has already pointed out, any member of the Admins group can "unlock" the Shift key bypass.
To really lock an Access application down tight you need to implement full blown User Level Security
(ULS) with all the bells and whistles. ULS is a difficult subject to grasp the first time or two and
most everyone misses a step or two the first time out. Just take a look at the posts in the security
NG to see that first hand!

To fully understand ULS I would recommend ALL of the following study material:

Access User-Level Security:

Security FAQ (the Security Bible):
http://support.microsoft.com/?kbid=207793

Jack Macdonald's Security Document:
http://www.geocities.com/jacksonmacd/AccessSecurity.html

Lynn Trapp's Ten Security Steps:
http://www.ltcomputerdesigns.com/Security.htm

Joan Wild's Tips:
http://www.jmwild.com/security02.htm

I also found the security chapter in the ADH book extremely helpful.

Practice on throw-away databases until you get everything down pat.

As you are applying security, set up RWOP queries for all data tables in the BE and deny all
permissions to the tables themselves. Create custom menu bars and toolbars and hide any built-in
Access ones. Lock things up tight under Tools | Startup and distribute MDE files to protect the
code. Also, create a distributed MDW file to give to users instead of the MDW file you used to
secure the database. Further, deny all groups and users various abilities to keep snoopers out. If
done properly there will be no one who is a member of the Admins group in the distributed MDW file
with the ability to do anything, so therefore no one can hold down the shift key to bypass your
Startup options.

Got all that?


Is this a lot of work? Yes!
Does it take a lot of time to get everything right? Yes!
Is this necessary in all cases of database development? Certainly not.
It all depends on WHAT you're trying to protect and WHO you're trying to protect it from.

But, even the most *secure* Access database can be hacked by a true determined hacker (or
cockroach). Whichever term you prefer.

 

[Alicia]

Well I did all of the above almost.
I have all the startup options locked up,
I have the shiftkey disabled and set to not allow further
modification,
I have set a default custom menu that has only copy paste
and exit,
Now I find that I can't get into the data any more even
if I do the shift-rightclick-open or anything else.
Thanks everyone for your help.

 

[Alicia]

I have not tested re-enabling the shiftkeybypass, but I
think that only an administrator is supposed to be able
to do it. I also don't know what defines an
administrator.

 

[Guest]

The best thing to do for that is to set the security for that application on
your server if you are running NT or 2000, etc. If you are the administrator
and can set security up on your server, if you have it on a shared drive,
right click it, go to security, make yourself the owner if your not, add
yourself and give yourself full rights, remove everyone else. This is if you
log on to your computers.