Limit the number of times users can re-enter a password

[anewuser]

Hi,

I have designed a database with a multi-user login function. However the code I have used (shown below) does not restrict the number of times users can re-enter a password.

Option Compare Database
Private Sub Login_Click()
UserName.SetFocus
If UserName = "Staff1" And Password = "Staff1" Then
MsgBox "Welcome"
DoCmd.Close
DoCmd.OpenForm "Staff1"
ElseIf UserName = "Staff2" And Password = "Staff2" Then
MsgBox "Welcome"
DoCmd.Close
DoCmd.OpenForm "Staff2"
ElseIf UserName = "Manager1" And Password = "Manager1" Then
MsgBox "Welcome, please exercise caution when changing query or table conditions", vbInformation, "CDSignatures"
DoCmd.Close
DoCmd.OpenForm "Manager1"
Else
MsgBox "Please re-enter Username and Password"
End If
End Sub

Is there a way of doing this, if so, can the program also be terminated after this sequence and the individual user locked out.

[zmbd]

Several ways of doing this:

If you want to "lock" a user out then you can use a table and record the number of tries and then flag the user account and then docmd to exit.

What I tend to do if I don't want to lock the user out is a do while loop wherein the loop has a counter that increments by one and a boolean flag in an "OR" arrangement. IF the password is valid the flag is true... or the count is exceeded then the flag is false.... true flags run the rest of the code... false flag and the application exits access.

Third way... when I really want to cause user's grief with lockout is to flag their user record... but I also put a flag in the user's roaming profile (our company uses a roaming profile; thus, with the right access one can write a value to the registry that follows the user .... evil laugh!)

One more way...and I've only just read about it so I haven't tried it yet is to cause the workstation to lock; thus, requiring the user to re-enter their workstation password. Haven't read thru the code yet so I don't know how useful it will be in this situation; however, in my company, the IT Dept has set the max bad attempts at 3 and then the user has to call the "Help" desk to reset... and that follows them too!

[anewuser]

Sorry, I am very new to access. I am using 2007 what's the loop code that I can use?

[TheSmileyCoder]

First off we need information from you. Would you like the app to just exit after X attempts? Basicly this means user can just re-open the database and try again.

Or do you want the users account to be locked until re-opened by an admin?

Finally, with security, you need to remember to strengthen the weakest point, not the strongest. There is no need to re-inforce the locked door if the window is left wide open. If the users are still allowed access into the db by holding down shift, then the use of a "3-strikes" policy seems overkill.

[anewuser]

I would like to lock users out until admin unlock them.

And your right about the shift key is there a way stopping this from being used?

[TheSmileyCoder]

Yes and no. The shift Key can be disabled by running a bit of code, but can also be re-enabled by running the same piece of code by someone with experience.


If you want to lock users out, the basic principle would be to have their user record store the number of failed attemps, and check that before letting the user login. On succesfull login you should then reset the counter back to 0.

[anewuser]

Is there a code for this, sorry I know I am asking a lot of questions.

[TheSmileyCoder]

There is no simple code for this, one of the reasons being that you should use encoding of any passwords stored.

I have seen way to many databases implemented in which I could plainly find and view users clear-text password in less then a minute.

I have been considering covering the topic as an article but I feel its requires a bit more effort then I can justify using here, at the moment.

[NeoPa]

ANewUser:
Is there a code for this, sorry I know I am asking a lot of questions.

As per the site rules, we do not simply write code for those that request it. We help and guide a member through their own learning process. How much we write depends on what we see coming from the member, so basic requests for code are often left hanging.

That said, we're more than happy to help you develop code. As a member, we expect you to be interested in learning the skills rather than simply wanting work done for you.