Dangerous Shortcut Keys?

A combination of the AutoKeys macro and code in your form will trap pretty much anything. Here's a good listing of items which you should consider disabling:

http://c85.cemi.rssi.ru/access/Books/A97ExSol/index17.htm

Look for the section titled "Trapping Dangerous Keystrokes" about halfway through the document. The author goes into detail about how to accomplish this. It's marked as Access 97 but this particular topic applies to any version of Access.

Rick,
Well said.

As usual, there are many way to accomplish the same thing in Access. When I create my databases, I use the following bulletproofing measures (which by the way I learned some time ago from the excellent link that LSMConsulting refers to) :
- ULS
- users only have access to forms
- Disable the AllowBypassKey
- convert to MDE file
- secure the startup optins (eg hide the database window, do not allow full menus, disable special
  access keys (which includes {F11})

Having done all that, I'm not aware of any shortcut keys that can bypass or undo any these bulletproofing measures; that is, there is no way for a user to use shortcut key strokes to:
- open the database window
- read/ write/ update/ delete/ add data other than via my forms.
- read the design of my database.
- write data in a way that would bypass any of my referential integrity or validation rules.

Am I correct?

If you have _correctly_ implemented User Level Security, then users wouldn't be able to read/write etc data unless they have a valid username/password. Of course, even with ULS correctly implemented, a malicious person could purchase software which would expose the names and passwords, so you data is only as secure as that. This would hold true for users writing data that would violate your referential integrity rules as well - if they can open the database, then they could conceivably circumvent your rules and such.

Hi LSM,
I have some tables that are used only by database code; eg.,a LogInHIstory table. Although the users are never supposed to see these tables, they must have read and write access, else the code can't do its job. Therefore ULS won't help me protect these tables, and I need to use other measures, such as  keeping the database window hidden.

I realize there are ways to circumvent my bulletproofing measures, but my question is specific to shortcut keys: are there any SHORTCUT KEYS that can bypass or undo any of my bulletproofing measures.

Using the AutoKeys Macro and establishing shortcut keys to overide the action Access would normally take will prevent your users from using those shortcut keys for the purpose they normally serve.  There aren't any bypass keys that will overide this.  Even so, there are alternative ways of doing the same thing so as long as you're content to prevent the users action via the shotcut keys knowing that an alternative method may still exist you're set.

Rick

You can remove all access to your tables if you implement data access through RWOP (Run With Owner Permission) queries ... you can then control exactly who has access to those RWOP queries and what, exactly, they can do with them. The queries would be in the frontend, so in theory your backend would be as protected as possible. Users could NOT link to the backend (without breaking your security) from other applications, and therefore your data would be as secure as you can make it with Access (remembering that anyone with a credit card and an internet connection can quickly break ULS).

If you do not implement ULS in this manner, then there is no way to stop users from linking to your tables and doing what they wish with the data. This could be done from Access, Excel, or many other environments.

From within your program itself, the methods you are currently using are about as good as you can get, assuming you've trapped all the shortcut keys at the link I provided above.

From the last two posts, I guess I didn't do a job good explaining my question. Let me try again...
When I create my databases, I use the following bulletproofing measures:
- ULS
- users only have access to forms
- Disable the AllowBypassKey
- convert to MDE file
- secure the startup optins (eg hide the database window, do not allow full menus, disable special access keys (including {F11}).

My questions:
Is there any way for a user to use SHORTCUT KEYS to bypass/ undo any of these bulletprooofing measures?
Also, once I've implemented these bulletproofing measures, is there any way for a user to use SHORTCUT KEYS to:
- open the database window
- read/ write/ update/ delete/ add data other than via my forms.
- read the design of my database.
- write data in a way that would bypass any of my referential integrity or validation rules.

LSM:
<If you do not implement ULS in this manner, then there is no way to stop users from linking to your tables and doing what they wish with the data. This could be done from Access, Excel, or many other environments.>
This is a good point and something I didn't think of. Thanks. I will think about rewriting my code to use RWOP queries instead of accessing the tables directly.

I didn't thoroughly read your question, sorry about that:

In short, yes, you should be trapping all "dangerous" Access keystrokes. These shortcut keys could certainly be used to do damage to your data. For example, a Ctrl + A followed by a Delete could certainly delete the current record, and if your form is in datasheet view could delete all records from that form. You would do well to follow mine and Rick's advice and implement the AutoKeys macro, as well as trapping other dangerous keystrokes in your form. The link I provided above is pretty thorough in regards to which keystrokes to trap, but in addition I'd also trap the Ctrl + X and Ctrl + c and Ctrl + V keys ...

Also: You mentioned startup options, but didn't specify which ones you've set and what settings you made. Specifically, if you have left the default Menubar in place, users would be able to use Tools - Startup to change any of those options and restart, with full admin priveleges. To further bulletproof, you'd want to build you own Menubar and use that in place of the default menubar (and also disallow menubar changes and customizations).

You'd also want to disable shortcut menus for your forms and reports, and provide your own context-specific shortcut menus.

Hi LSM,
I understand how some of the 'dangerous' keystrokes could affect data, and that it may be a good idea to disable them, however, my question is very specific; that is:
- can any shortcut key bypass or undo any aspect of ULS?
- can any shortcut key reenable the AllowBypassKey property once it has been disabled?
- can any shortcut key change the startup options?
- can any shortcut key open the database window if I have disabled the 'Use Access Special Keys' Startup option.
- can any shortcut key allow the user to read/ write/ update/ delete/ add data other than via my forms, if I have designed the database so that users only have access to data via my forms.
- can any shortcut key read the design of my database if I have set up ULS and MDE to disallow this.
- can any shortcut key cause data to be written to my tables in a way that would bypass any of my referential integrity or validation rules.

I believe the answer to all of these questions is no, but I'm looking for confirmation.

Hi LSM and thanks for your detailed response. Sorry I didn't reply earlier (sometimes my job interferes with my life).

I'd like your opinion on a couple of points:

< Users could open the db via automation and re-enable the key, but if you have a user sophisticated enough to do that then you'll not keep them out anyway.>
I use dual Work Information files (WIFs) for my databases (one for the users, and one that only the developer (me) has access to). Because only the administrators and database owner can change database properties such as the AllowByPAssKey, and their SIDs aren't  in the user’s WIF, users/ hackers can't re-enable the Bypasskey. Am I correct?

<...users could re-enable your startup options if you don't do away with the builtin Access menus.>
I set AllowFullMenus = False, so they can't re-enable the startup options. Am I correct?

<...Ctrl + A and Delete will delete all records in a form's recordset..>
I assume this is only possible if the form properties and the ULS permissions allow deletions. Am I correct?

<<- can any shortcut key cause data to be written to my tables in a way that would bypass any of my referential integrity or validation rules.> Possibly, depending on how you've implemented your integrity and validation rules. If you've done so at Table or DAtabase level, or through the Form's Update events then no. If you're validating elsewhere (like on a button click event) then any key combo which would save the data would circumvent those routines.>
-Any action that would save the data, such as moving to the next record or closing the form, would also circumvent those routines, so there is no way to stop circumvention anyway. Am I correct?

<Because only the administrators and database owner can change database properties such as the AllowByPAssKey>

That depends on how you created those properties. If you did NOT use the fourth argument (the DDL argument) of the CreateProperty method, or you created the property by using the Tools - Startup screen, then any user can change those arguments. See the CreateProperty method in online help for more info.

<I set AllowFullMenus = False, so they can't re-enable the startup options. Am I correct?>

Right - they couldn't re-enable those menus from within the application, but if they managed to open it via automation then they could certainly do so.

<I assume this is only possible if the form properties and the ULS permissions allow deletions. Am I correct?>

Yes - if you've setup the tables correctly, and removed the correct permissions, then the Jet engine would disallow this.

<-Any action that would save the data, such as moving to the next record or closing the form, would also circumvent those routines, so there is no way to stop circumvention anyway. Am I correct?>

You can "catch" those movement by using a global variable, and querying that variable in the Form's BeforeUpate event ... so in effect you can "catch" the user before allowing Access to update and force the data to run through your validation routines. For eg:

In the form's General Declarations section:
[General Declarations]
Private mflgSave As Boolean

Sub Form_BeforeUpdate(Cancel As Integer)
  If mflgSave=False Then
    If msgbox("Do you want to save these changes?", vbYesNo) = vbNo Then
      Cancel = True
      Me.Undo
      Exit Sub
    End If
  End IF

    <run your validation routines here>
    If Not ValidateData Then
      Cancel= True
      MsgBox "The data didn't validate. Press the Esc key to undo current changes, or review your data and try this again.", vbOkOnly+vbExclamation
    End IF

End Sub

Sub Form_Current()
  '/reset the module flag
  mflgSave = True
End Sub

Sub Form_Dirty()
  '/user has changed something - set the flag so the BeforeUpdate event will catch it
  mflgSave= False
End Sub

You could also provide the user with a Save button:

Sub btnSave_Click()
  mflgSave=True
End Sub

This would set the module flag to True, and the BeforeUpdate event would simply run its' course ...

Well, You guys earned your points on this one. Hopefully you don't to spend this much effort too many questions.
I'll split the points: 100 for Rick and 400 for LSM.

Thanks to you both!