How do I lock the unhide database window menu option?

[Guest]

We are using Office XP and 2003. I have a database that contains sensitive
information that I would like to secure. It consists of a front end with all
the forms, queries, and reports and a linked backend that contains the
tables. I have turned off the special access keys to disable the F11 key to
open the database window but there is still the matter of the user going to
Window->Unhide and viewing the database window that way. I thought about
customizing the menu bar and removing that option but I still need to be able
to access it. Is there a way to password protect the database window only? I
do not want to have to manage users in Access. I want the general user to be
able to open the database, view their forms and reports but not be able to
open the database window or modify the menu bar to see the database window.
But I need to be able to get to it periodically to do maintenance. Basically
I do not want the users to be able to get to the underlying tables and see
the data.

 

[Scott McDaniel]

We are using Office XP and 2003. I have a database that contains sensitive
information that I would like to secure.

First things first: If you have truly sensitive information, Access is NOT the place to store it. Consider moving your
data storage to a true server database (MS SQL Server, MySQL, Oracle, etc) if you need real security. Access security is
weak and easily broken.

It consists of a front end with all

the forms, queries, and reports and a linked backend that contains the
tables. I have turned off the special access keys to disable the F11 key to
open the database window but there is still the matter of the user going to
Window->Unhide and viewing the database window that way. I thought about
customizing the menu bar and removing that option but I still need to be able
to access it.

You can build a menubar that does everything the default menubar does, then tell Access to use that menubar (in the
Startup options).

Is there a way to password protect the database window only?
No.

I do not want to have to manage users in Access. I want the general user to be
able to open the database, view their forms and reports but not be able to
open the database window or modify the menu bar to see the database window.
But I need to be able to get to it periodically to do maintenance. Basically
I do not want the users to be able to get to the underlying tables and see
the data.

You can secure an Access database without requiring a login; see Joan Wild's site for info on this:

www.jmwild.com

Regarding maintenance - you can always turn the database window back "on", then restart Access ... you can also provide
certain users with a different menu (i.e. an Admin menu, a Developer menu, etc etc) so that certain users or groups of
users would have access to different portions of Access. This is typically done in your startup form where you might
show/hide menu items based on username, user Group membership, etc etc ...

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Chris Mills]

First things first: If you have truly sensitive information, Access is NOT
the place to store it. Consider moving your

data storage to a true server database (MS SQL Server, MySQL, Oracle, etc)

if you need real security. Access security is

weak and easily broken.

This can be a bit of a glib statement, since SQL Server for instance, requires
something else as an intimate front end. Such as, MS-Access!!! (!!!!!) So if
they can break into MS-Access, then they can get into SQLServer data!!!
(!!!!!) (depending on the password procedures etc, but ALWAYS they will have
access to data they are authorised to view, in this case in tabular mode which
the developer might not want them to have!)

And depending on circumstances, such as physical security, ALL such products
can be broken. All of them! Except where the PROGRAM is ALSO stored on a
"server", for example, internet or intranet-based systems such as Oracle has
been promulgating for a long time.

Whilst I don't go to this extent myself, I thought AllowBypassKey disables all
such activities, and if customised menus and toolbars are also used, then you
don't need Window in the menu anyway!

AllowBypassKey is Dangerous! For development you need a way to Re-Enable it!
Perhaps an invisible miniscule command button somewhere, anyhow the exact
details don't matter because they would be known only to you.

/Runtime disables these things. But of course, that's not secure because
anyone can remove it from the command line. Unless of course the user only had
Access Runtime.

One must ask oneself, WHY don't you want them to see the tables? You have
already given them access to the data contained. I myself like to limit them
to just the forms I have written, but it is NOT a security issue, it's a
"dummies doing silly things in the program" type of issue.

Chris

 

[Scott McDaniel]

the place to store it. Consider moving your
if you need real security. Access security is
This can be a bit of a glib statement, since SQL Server for instance, requires
something else as an intimate front end. Such as, MS-Access!!! (!!!!!) So if
they can break into MS-Access, then they can get into SQLServer data!!!
(!!!!!) (depending on the password procedures etc, but ALWAYS they will have
access to data they are authorised to view, in this case in tabular mode which
the developer might not want them to have!)

I don't see it as glib ... it's pretty much common knowledge that Access/Jet security is really no security at all, and
that SQL Server, Oracle, etc are far more secure. My comment was intended to alert the poster that Access/Jet is not a
secure data store. I'll grant you that any database system can be broken, but the effort required to break User Level
SEcurity on an Access database is generally about 3 minutes, a credit card, and a search engine. Not so with server type
database.

Of course, as you mention, SQL Server and others require some sort of frontend, and as you mention, the "security" is
only as good as the frontend. If the dev allows direct access to the tables through the frontend, then you must assume
that the dev intends for them to work with that data, and that the program/frontend would limit or determine what the
user could do with the data ... at this point, the onus would be on the dev to insure that the data is "protected",
whether it be from innocent or malicious intent.

And depending on circumstances, such as physical security, ALL such products
can be broken. All of them! Except where the PROGRAM is ALSO stored on a
"server", for example, internet or intranet-based systems such as Oracle has
been promulgating for a long time.


Whilst I don't go to this extent myself, I thought AllowBypassKey disables all
such activities, and if customised menus and toolbars are also used, then you
don't need Window in the menu anyway!

AllowBypassKey is Dangerous! For development you need a way to Re-Enable it!
Perhaps an invisible miniscule command button somewhere, anyhow the exact
details don't matter because they would be known only to you.

/Runtime disables these things. But of course, that's not secure because
anyone can remove it from the command line. Unless of course the user only had
Access Runtime.

One must ask oneself, WHY don't you want them to see the tables? You have
already given them access to the data contained. I myself like to limit them
to just the forms I have written, but it is NOT a security issue, it's a
"dummies doing silly things in the program" type of issue.

Chris

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Chris Mills]

I don't see it as glib ...

I meant with insufficient qualifying detail of course, not that you dont have
it!

it's pretty much common knowledge that Access/Jet security is really no security at all, and
that SQL Server, Oracle, etc are far more secure. My comment was intended to

alert the poster that Access/Jet > is not a secure data store.

Perhaps in a direct comparison, there are two reasons a)Access passwords more
easily breakable b) SQL Server, whilst still "file-based", indeed has no
direct user-access to the file, or not in normal user circumstances.

But if a solution is implemented which is Internet/Intranet-based, the user
also does not have direct access to the files because there is no such
connection. They just have a .asp or like returning vetted data.

Therefore, in such circumstances (and ignoring IT personnel at the premises),
it wouldn't matter if the database was Access or SQL Server, or indeed no
ULS/password security at all for the data file itself?

Web-based (or "intranet-based") would depend entirely on some other
implemented user/password system, to do with the .asp?

But given not using intranet system/methodology (and I don't, yet), it seems
only true to say SQL Server is more secure than Access in SOME RESPECTS
(password cracking, obviously). It doesn't do much for abuse of allowed
access! Rick Brandt partially addresses this in his short statements (like,
depending on whether you want to protect from someone inside or outside the
organisation)

Whilst I fully appreciate the breakability of Access (god-knows I have a
history on the subject!), there are also cases where SQL Server improved
security is totally irrelevant. For example, in "shrink-wrapped" software my
concern is ripping off the software not the data! (the customer owns their
data not me) Well, in Access, the prog is just as easy to rip-off for sure
<guffaw>. And SQLServer does nothin' for me! However, quite clearly, I was
just making a point that there's a galaxy of reasons and practical
restrictions regarding what exactly security is for? Without knowing the
reasons and restriction criteria of the poster, I have no idea whether SQL
Server is a sensible suggestion or not!

To me, "sensitive info" means, say, what other similar employees may be
earning! Only the likes of accountants actually need that info. I wouldn't
rely on Access or SQLServer security. I'd put that in a SEPARATE
table/database which has RESTRICTED PHYSICAL ACCESS. (physical may mean the
restricted electronic paths to it)

Sensitive info...unfaithful love letters...oops I gotta go and check
something...

Thanks for a "robust" discussion!
Chris

 

[Chris Mills]

Furthermore, "Client/Server" was intended for performance, not security per
se. It has nothing to do with security, of itself.

"Terminal Server" establishes the same thing as "Client/Server" in many
respects (centralised program/processing). So it is not the "Client/Server"
aspect which you are claiming enhances security, but the actual product itself
rather than it's methodology. In SQL Server, the only security advantage seems
that the password is purported unbreakable. Well, not by a quick search of the
internet....LESS breakable would be true...

Alrighty I'll go now

 

[Scott McDaniel]

Furthermore, "Client/Server" was intended for performance, not security per
se. It has nothing to do with security, of itself.

"Terminal Server" establishes the same thing as "Client/Server" in many
respects (centralised program/processing). So it is not the "Client/Server"
aspect which you are claiming enhances security, but the actual product itself
rather than it's methodology. In SQL Server, the only security advantage seems
that the password is purported unbreakable. Well, not by a quick search of the
internet....LESS breakable would be true...

Right. I'm saying that, in a side-by-side comparison, MSSQL\MySQL\SyBase\Oracle et al will be more secure than will be a
Jet database. There are some definite plusses to Jet - it's portable, easy to work with, requires no real technical
competence to setup or maintain, requires no specific hardware - but the downside is the lack of real security. Of
course, I don't think MS ever really intended it to be secure, and we (as in the Access/Office developer community) have
tried, on occasion, to make it that way.

I see other security advantages with server-type database engines as well. It's far too easy to grab a Jet datafile,
take it home with you, and hack it at your leisure. That's a bit more difficult to do than with a server-type engine,
where the admin could impose significant Windows-based restrictions on who could access the actual datastore.

Of course, anything built by man can be destroyed by man ...

Alrighty I'll go now

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Chris Mills]

You might also want to consider disabling a form's tabular view, that is, in a
form, View, Datasheet view. By default, this view is available, much like a
table.

....it only takes "Select All" "Copy" to copy it all out!!!

I disable these menu things, along with every other view and option I don't
want
the user to have, by "customising" the menus/toolbars. Including using the
runtime option of Access, where ONLY customised menus/toolbars are allowed. In
a well-tied-down-app, I don't see much use for the std menus/toolbars, or not
most of the default options, or I have found toolbars more usefull than menus
for restricted quick options.

The above (menu restriction) does NOT disable (copying out bulk data the user
has access to), because I believe "Select All" "Copy" works in almost any
mode! But at least it's restricted to knowing the keystrokes, rather than
staring you in the face.

All these considerations apply, even if you shifted data to SQL Server and
retained Access or similar as a Front End!

I spent a lot of time, once, trying to tie-up a form so that you couldn't copy
out data, or at least bulk data. Including disabling <ctrl A> <ctrl C> things
like that. I cannot say I was successful. Perhaps to an end-user, but
certainly not to any reasonable expert in these newsgroups.

I even tried encrypting individual table data, so that the table itself
appeared garbage! Fine! Though I expect any smart person here could have
broken it if so minded. Are my users so expert? Or so-minded?

Did I mention RWOP queries? (look it up in Help). RWOP is a way of hiding
"sensitive info" by removing certain fields or the table directly, from a
given user. This was specifically designed to address your question of hiding
"sensitive info", methinks. Of course, it relies on Access Security being
intact, and for sure Scott has a point there! I'd physically separate such
stuff.

It seems to me, that ALL advice here on securing an Access program, relies on
the presumption of ULS being unbroken. In some ways laughable, in other ways,
why do we regularly have even Access Programmers asking about it here? It may
just take a few minutes to break, with the right tools, and anyone reading
this ng could do it, but why is it that others (users, other programmers
unfamiliar with Access or who have not studied it) by-and-large get a blank
look on their face? Or do they?

Furthermore, "sensitive info". Where'd that come from? Paperwork? Removable
disk media? Import/Export files? Were those files deleted securely? (one
proprietary OS I worked on had a DELETE;SHRED option, Windows certainly
doesn't). I see, totally secure in SQLServer with copies floating around
everywhere! Backup tapes which can be taken home! Are all these OTHER holes
overkill for a given application? (answer: it's for the developer to decide in
the circumstances)

Chris

 

[Guest]

Here is what I eventually did to lock down the Database Window. The Main
form is set to load on Startup and in the code there is this function that I
found and adapted from "Programming Microsoft Access Version 2002" by Rick
Dobson (pg601):

Private Sub NoHideUnhide()
Dim cbr1 As CommandBar
Dim ctl1 As CommandBarControl

'Disable and make invisible Hide and Unhide Commands on the Window menu
Set cbr1 = CommandBars("Window")
For Each ctl1 In cbr1.Controls
If ctl1.Caption = "&Hide" Or ctl1.Caption = "&Unhide..." Then
ctl1.Enabled = False
ctl1.Visible = False
End If
Next ctl1
'Disable the startup command on the Tools menu
Set cbr1 = CommandBars("Tools")
For Each ctl1 In cbr1.Controls
If ctl1.Caption = "Start&up..." Then
ctl1.Enabled = False
ctl1.Visible = False
End If
Next ctl1

'disable ability to open customize dialog box
Application.CommandBars.DisableCustomize = True

End Sub

The Form_Load checks the userName of the logged in user and then so long as
it is not me, runs the NoHideUnhide(). I also went to Tools->Startup and
unchecked the box for Use Special Access Keys.

Then I also found this bit of code that can be placed in it's own module and
ran to disable the Shift key (AllowBypassKey property) on database open
(http://msdn2.microsoft.com/en-us/library/Aa223277(office.11).aspx):

Sub SetBypassProperty()
Const DB_Boolean As Long = 1
ChangeProperty "AllowBypassKey", DB_Boolean, False
End Sub

Function ChangeProperty(strPropName As String, varPropType As Variant,
varPropValue As Variant) As Integer
Dim dbs As Object, prp As Variant
Const conPropNotFoundError = 3270

Set dbs = CurrentDb
On Error GoTo Change_Err
dbs.Properties(strPropName) = varPropValue
ChangeProperty = True

Change_Bye:
Exit Function

Change_Err:
If Err = conPropNotFoundError Then ' Property not found.
Set prp = dbs.CreateProperty(strPropName, _
varPropType, varPropValue)
dbs.Properties.Append prp
Resume Next
Else
' Unknown error.
ChangeProperty = False
Resume Change_Bye
End If
End Function

This pretty much took care of what I was trying to accomplish with locking
down the Database Window. I'm sure it can probably still be broken by someone
knowledgeable enough but it is a step in the right direction. The data is not
terribly sensitive, critical data but something that deserves to be locked
down more than just hiding the database window where any one can easily
restore it.

Thanks for your help.

RS

 

[Guest]

RSharp.

I am trying to do the exact same thing and lock the database window so it
can not be un hidden. My databas is also set to open the "Main Menu", where
about should i put this coding:

Private Sub NoHideUnhide()
Dim cbr1 As CommandBar
Dim ctl1 As CommandBarControl

'Disable and make invisible Hide and Unhide Commands on the Window menu
Set cbr1 = CommandBars("Window")
For Each ctl1 In cbr1.Controls
If ctl1.Caption = "&Hide" Or ctl1.Caption = "&Unhide..." Then
ctl1.Enabled = False
ctl1.Visible = False
End If
Next ctl1
'Disable the startup command on the Tools menu
Set cbr1 = CommandBars("Tools")
For Each ctl1 In cbr1.Controls
If ctl1.Caption = "Start&up..." Then
ctl1.Enabled = False
ctl1.Visible = False
End If
Next ctl1

'disable ability to open customize dialog box
Application.CommandBars.DisableCustomize = True

End Sub

If you could let me know id be very grateful

 

[Guest]

This should go in the code for the first form that loads when you open the
database. My main menu form that loads when I open the database is called
Main, so I would open the Visual Basic code editor and go to the code for
Form_Main and put a call to the NoHideUnhide function in the Form_Load
function like this.

(Before you do this however, make sure you have a spare copy of your
database for yourself that you don't put this code. This is just in case you
need to make changes later because you won't be able to get in either.)

'you should be able to just copy all that follows and paste this
'into your Form_Main or Form_WhateverYourMainFormIsCalled code

Private Sub Form_Load()
Call NoHideUnhide
End Sub

Private Sub NoHideUnhide()
Dim cbr1 As CommandBar
Dim ctl1 As CommandBarControl
'Disable and make invisible Hide and Unhide Commands on the Window menu
Set cbr1 = CommandBars("Window")
For Each ctl1 In cbr1.Controls
If ctl1.Caption = "&Hide" Or ctl1.Caption = "&Unhide..." Then
ctl1.Enabled = False
ctl1.Visible = False
End If
Next ctl1
'Disable the startup command on the Tools menu
Set cbr1 = CommandBars("Tools")
For Each ctl1 In cbr1.Controls
If ctl1.Caption = "Start&up..." Then
ctl1.Enabled = False
ctl1.Visible = False
End If
Next ctl1
'disable ability to open customize dialog box
Application.CommandBars.DisableCustomize = True
End Sub

 

[Guest]

"'you should be able to just copy all that follows and paste this

'into your Form_Main or Form_WhateverYourMainFormIsCalled code"

Where do i find this code for my Main form, i cant seem to find any code
that has a title of my main form!?