Re: setting a password on a button on the switchboard

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Jeff Conrad (jeffc_at_ernstbrothers.com)
Date: 04/22/04 

Date: Thu, 22 Apr 2004 13:35:52 -0700

Yes, there is a lot to know about security whether it's something you make or it is Access User
Level Security. I'll send the sample along, but again I caution you to realize that this could
easily be circumvented. Just want you to understand it's limitations.

I'm out of the office and I only have the Access 97 sample with me here.
1. Unzip the file.
2. Read the ReadMe text file first.
3. Hold down the shift key and open the database.
4. Convert to your version.
5. Open the converted version without holding down the shift key to see the login screen.
6. Read the Read Me form in the database for more info.

Hope it helps.
On it's way. 

-- 
Jeff Conrad
Access Junkie
Bend, Oregon
"Karen" <knospamskipper@nolamottespam.com> wrote in message
news:eS6GEBKKEHA.2244@tk2msftngp13.phx.gbl...
> Wow Jeff,  I didn't know I had so much to study just because I want one
> button passworded!
>
> Could you send me the sample database for the fourth option (4. To get even
> more advanced you could create a table of users and user levels. Each user
> would need
> to log into the database )?
>
> My email address is
>
> knospamskipper@lamotte.nospamcom
>
> Leave out the nospam, of course.
>
> Thanks for this inforamation.
>
> Karen
>
> "Jeff Conrad" <jeffc@ernstbrothers.com> wrote in message
> news:eQl4lxJKEHA.952@TK2MSFTNGP12.phx.gbl...
> > Hi Karen,
> >
> > Here's a past post of mine on this subject which should give you some
> ideas.
> >
> > Let me provide my *few* thoughts about Access Security.
> >
> > Security in an Access database can probably be broken down into two big
> categories: home-grown
> > security or Access
> > User Level Security. A "home-grown" system is something a developer
> creates themselves to control
> > access to various
> > aspects of a database. User Level Security is using the "built-in"
> security features available in
> > Access. They
> > each have their advantages and disadvantages. User Level Security,
> incidentally, is always being
> > used in EVERY
> > database, it is just well *hidden* until activated to its full potential.
> >
> > Now some may disagree with me, but I believe there is a time and place for
> using either security
> > system. A BIG but
> > coming here....as long as you FULLY understand the limitations of both
> models. Yes, even User Level
> > Security
> > has some limitations, but FAR less than anything made up.
> >
> > Here are some advantages of using a home-grown system:
> > 1. Can be VERY quick and easy to set up.
> > 2. Can be just about as complex as you want it to be.
> > 3. Can be very easy to maintain.
> > 4. Can sometimes be all that is really needed.
> > 5. You can pat yourself on the back for making it. <g>
> >
> > Please note that each sentence starts with the word "can." This is not
> always the case however! Some
> > may argue the
> > points about being easier than User Level Security, but I can guarantee
> that every one of those
> > people has been
> > using that model for a LONG time and know it inside and out! For a
> beginner, it can be a daunting
> > task.
> >
> > Here are some advantages of using User Level Security:
> > 1. A developer can have complete control over EVERYTHING in the database.
> > 2. The developer can *properly* secure all objects in the database.
> > 3. Permissions can be assigned object by object.
> >
> > Now let's get to the disadvantages! The Achilles heel of an Access
> database when you get right down
> > to it is
> > securing DATA. Code can easily be secured by converting to an MDE file.
> Forms and reports can easily
> > be duplicated by
> > seasoned developers just by looking at someone else's work. But, DATA is
> what it all comes down to.
> > If someone
> > wants to try and "crack" into your database, why would they? Well, about
> 99% of the time it's
> > because they want
> > to look at your DATA. Period. And this is where home-grown systems will
> fail virtually every time.
> > No matter how
> > sophisticated a home-grown system is, any really good Access developer
> could probably get to the
> > data faster
> > than you can say, "Would you like fries with that data?"
> >
> > With User Level Security you can control access to the data tables
> themselves. When you get right
> > down to it,
> > this is what it's all about and that's why home grown systems will always
> be inferior. Now if you
> > really want to
> > get technical, even properly secured Access databases can be cracked into
> by true hackers because
> > they have access
> > to the file. For the best database security you need to look at SQL or
> Oracle which is server-based.
> > For the sake
> > of argument let's forget about the full time hackers.
> >
> > Yes, there are programs out there that can easily read user information
> stored in MDW files. Which
> > begs the
> > question, why take all the time to use User Level Security if someone can
> get log in information so
> > easily?! Well, if
> > you REALLY follow all the steps in the Security FAQ (discussed in the next
> chapter further down) and
> > create a
> > distribution MDW then that information can be pretty useless for getting
> at everything.
> >
> > OK, so why would you want to use home grown systems in various situations?
> Well, the best answer I
> > can give is to
> > ask yourself two questions:
> > What type of data are you trying to protect?
> > How savvy are your users?
> >
> > With non critical and/or non personal data, full blown User Level Security
> may not really be needed.
> > Also, if you
> > have real low-tech users it may not be warranted to take the more secure
> route. So I believe each
> > situation needs
> > to be evaluated independently. As long as you fully understand the pros
> and cons of home grown
> > systems than
> > those may suit you just fine.
> >
> > I work mostly with VERY low tech users. I'm talking about people with
> trouble telling the difference
> > between left
> > click and right click! For these people, making my own security is WAY
> more than I probably need. I
> > could
> > probably just hide the desktop icon and they would have no clue how to
> open it!! So I do have
> > experience with setting
> > up some home brewed security as well as User Level Security.
> >
> > Now that we've got that covered let me offer just a few examples of ways
> to secure things.
> >
> > 1. Probably the simplest way to protect a form would be to ask for a
> password in the click event of
> > a command button
> > using the InputBox function. Something like this:
> >
> > ' Code Start
> > Private Sub cmdOpenForm_Click()
> > On Error GoTo ErrorHandler
> >
> > If InputBox("Please enter the Administrative " _
> >     & "password to gain access to this form.", _
> >     "Enter Password") <> "password" Then
> >     ' The entered password was incorrect
> >     MsgBox "Sorry, the password you have " _
> >     & "entered is incorrect." & vbNewLine _
> >     & "Please contact a Database Administrator.", _
> >     vbExclamation, "Access Denied"
> > Else
> >     ' The entered password was correct
> >     ' Open the protected form
> >     ' Then close this form
> >     DoCmd.OpenForm "frmProtectedForm"
> >     DoCmd.Close acForm, "frmSampleForm"
> > End If
> >
> > ExitPoint:
> >     Exit Sub
> >
> > ErrorHandler:
> >     MsgBox err.Description, vbCritical, "Error #" & err.Number
> >     Resume ExitPoint
> >
> > End Sub
> > ' Code End
> >
> > This is quick and easy. Making an MDE file will protect the password, but
> anytime you want to change
> > it, you have
> > to make another MDE. Also, anyone that needs this form will have to know
> the password. You can't get
> > more
> > detailed than that. In addition, by using the InputBox, you can't hide the
> password as you type it.
> >
> > I have a sample database showing this option in 97 or 2000.
> >
> > 2. A slightly more advanced approach would be to make an unbound form that
> has a text box with an
> > Input Mask set
> > to "Password" to hide the password as it is typed. This way someone
> looking over a shoulder may not
> > see exactly
> > what the password is. A command button on a form would open this special
> password form first. If the
> > correct
> > password is entered, then the "protected" form would open. Otherwise, they
> can't open it. You can
> > also add code to
> > help stop someone from opening the protected form directly from the
> Database Window.
> >
> > I have a sample database showing this option in 97 or 2000.
> >
> > 3. There is a Microsoft KB article demonstrating a method to password
> protect a form or report using
> > a neat KeyCode
> > function. You can find that here:
> >
> > http://support.microsoft.com/?id=209871
> > http://support.microsoft.com/?id=179371
> >
> > This still requires that everyone who needs to open this form have access
> to that password. I took
> > this a step
> > further and designed custom forms that you can use to easily
> add/edit/delete these KeyCodes in the
> > password
> > table. You can modify all the entries quite easily without having to open
> the table directly at all.
> >
> > I have a sample database showing this option in 97 or 2000.
> >
> > 4. To get even more advanced you could create a table of users and user
> levels. Each user would need
> > to log into
> > the database and you could code each form's Open event to check their user
> level. Using this
> > technique you can make
> > different forms/reports available to different groups. More coding and
> administrative work, but a
> > little more
> > control over individual users. You can also save records with the name of
> the person currently
> > logged in.
> >
> > I have a sample database showing this technique using 97 or 2000. You can
> create as many security
> > levels as you
> > wish and it's real easy to maintain in my opinion. I also incorporated the
> KeyCode technique from
> > the above
> > mentioned KB articles in this sample to further deter snoopers looking at
> passwords. This type of
> > system is what
> > I use on my low tech users. It's MORE than adequate for their experience
> level!
> >
> > There are countless other possibilities for creating something of your
> own. You're only limited by
> > your imagination.
> >
> > Let me know if you would like any of these samples.
> > Unfortunately I do not have a web site to post these on.
> >
> > 5. Here is another place with a sample file:
> >
> > http://www.angelfire.com/sports/f1pictures/AccQuestion6.htm
> >
> > 6. Your absolute BEST protection is to implement full blown User Level
> Security with all the bells
> > and whistles.
> > To study up on this I suggest the following materials:
> >
> > -Download the Security FAQ here (the Security Bible):
> > http://support.microsoft.com/?kbid=207793
> >
> > -Download Jack Macdonald's Security Document:
> > http://www.geocities.com/jacksonmacd/AccessSecurity.html
> >
> > Read Lynn Trapp's Ten Security Steps:
> > http://www.ltcomputerdesigns.com/Security.htm
> >
> > I also found the security chapter in the Access
> > Developer's Handbook very useful:
> > http://www.developershandbook.com
> >
> > Read ALL this material. Sleep on it. Read it again. Then practice on some
> trial databases until
> > you're really
> > comfortable with it. Always keep lots of backups. The Security Wizard in
> all versions seems to
> > always miss an
> > important step or two so that's why it may be better to do this on your
> own. It is a challenge and
> > you will most
> > likely make mistakes along the way, but keep at it! If you're running into
> problems there is a great
> > newsgroup
> > devoted to this subject here:
> >
> > microsoft.public.access.security
> >
> > Spend time there! You will get to know Joan Wild, Mr. Lynn Trapp, and many
> other helpful MVPs and
> > non-MVPs
> > personally! They will help you avoid the many pitfalls that people find
> out later seeing that their
> > database actually isn't really secure! An unasked question is an
> unanswered one.
> >
> > I would also recommend doing the following steps to further secure your
> database:
> >
> > 1. Disable the Shift key bypass option. Details here:
> > http://www.mvps.org/access/general/gen0040.htm
> >
> > 2. Create custom menu and toolbars for your forms and reports so the users
> only have access to
> > things they really need. A good read on this subject can be found here:
> >
> > http://www.microsoft.com/Accessdev/articles/bapp97/chapters/ba01_6.htm
> >
> > It is written for Access 97, but the same basic concepts apply to later
> versions as well.
> >
> > 3. Hide the Database Window.
> >
> > 4. Set limited Startup options.
> >
> > 5. Distribute only MDE files so no design changes can be made and no one
> messes up your code.
> >
> > Well I hope that helps a little with your security issues.
> > Good luck.
> > -- 
> > Jeff Conrad
> > Access Junkie
> > Bend, Oregon
> >
> > "Karen" <knospamskipper@nolamottespam.com> wrote in message
> > news:%23NPhrkJKEHA.1156@TK2MSFTNGP09.phx.gbl...
> > > Hi all,
> > > I'm thinking of trying to set a password on a button on the switchboard
> in
> > > my database.  I only want certain people to be able to see and/or use
> the
> > > form behind the button.
> > >
> > > Does anyone have any ideas on how this would be done?  I found an old
> post
> > > in the google search that gave two different ways to set a password on a
> > > single text box.  I see how this works but in the example the password
> is
> > > stored in the single table that the form is linked with.  In my database
> I
> > > think I would need a separate password table; but then again, maybe
> putting
> > > the password in the code would be better.
> > >
> > > Any Ideas on how I should approach this?
> > >
> > > Thanks in advance,
> > >
> > > Karen
> > >
> > >
> >
> >
>
>
Quantcast