Question Access 2003 - Regular password changes

[Peetee]

Can anyone help with how I might be able to force users to change their passwords every 60 days or so?

I can set up a table with userIDs and passwords, as well as a form which could set the "last updated" date and a further password expiry date.

The question is, how can I link this table/form to the real password and login ID that people use to access the database?

It's a security requirement at my company that passwords have to be changed regularly. I've looked on the forum and other web sites but can't seem to find any tips anywhere on this! Surely I can't be the only person to have attempted this?

Thanks,

 

[JoanneJames]

PeeTee:
I have the following code that I use...

dtePasswordExpires = Me.cboUser.Column(8)
If (DateAdd("d", 186, (dtePasswordExpires)) < Date) Then
If (DateAdd("d", 200, (dtePasswordExpires)) < Date) Then
MsgBox "Your Password has been used for over 6 months and is now expired." _
& vbCrLf & "Select the 'Change Password' button to change your password ", vbExclamation, Me.Name
Exit Sub
Else
If MsgBox("Your Password is due to expire in " & Abs(DateDiff("d", Date, dtePasswordExpires)) & " days." _
& vbCrLf & "Select yes, then select the 'Change Password' button to change your password now.", vbYesNo + vbInformation, Me.Name) = vbYes Then
Exit Sub
End If
End If
End If

the cboUser (field that accepts user name), gets data like so:
SELECT User.UserID, User.UserName, User.UserNameSys, User.CitrixFolder, User.Admin, User.EmployeeID, User.TeamID, User.AddsClasses, User.PasswordDateChg, User.Password
FROM [User]
ORDER BY User.UserName
WITH OWNERACCESS OPTION;

 

[JoanneJames]

Also - on the form that the user uses to change the password, the date they changed it gets stored in the user table.... so it then is available to be viewed & compared, in the login screen, as indicated in the code I presented...

 

[DCrake]

Simple Software Solutions

I have this analogy about passwords....

Passwords are like toothbrushes

Everyone should have one
They should change them regularly
They should not share them with other.

At the extreme

A user should have

A Windows login password
The MDB should be password protected
There should be a Login Screen with a username and password.

Users should not be able to have the same password for the mdb as their Windows password. The password must be changed at least every 30-60 days, depending on company policy. Passwords should not be reused. They should be a minimum of 6 characters containing both alpha and numeric digits.

Any mission critical operations carried out in an application such a record deletion should be restricted to high level users and also be governed by further password protection.

 

[Peetee]

Linking login ID/pwd to user permissions

Thanks for the toothbrush analogy, DCrake.

Thanks also, Joanne for your code. I see how the code would allow the password field to be updated.

What I'm not clear on is how to get the login and password field in the User table to update the actual Access login ID and password. Is that how you use it? Or do you set up Access so the Access security/permissions is not used and you use your own controls instead to provide this function?

I want different groups of users to have different permissions available to them.

Thanks.

 

[JoanneJames]

I do not use Access security/permissions. Instead I created the user table that gets updated/accessed via the a special user form, (to add users, set them as inactive, reset passwords, set them up as admin), the login screen and the password update screen. I also have a routine in place for allowing users into certain forms (or not).

 

[Peetee]

Thanks Joanne. I've been able to get password changes to work.

 

[Banana]

Two things I would want to add:

1) I don't believe in querying Users table for password; it should be a write-only operation with the backend server returning the result (did it match or not?). Ditto for linking the same table. I prefer to query the server to verify the password just in time.

2) I also make use of hashes (I personally use SHA-256) and strong salts and compare them. Again, the hashes are executed just in time.

This way, there should be no password/hash saved anywhere in Access environment as a variable, in ODBC connection string, in local tables and thus the user has to supply the missing parts at the time everytime. So even if my copy of Access got stolen, broken and decompiled, they could figure out my hashing mechanism (actually, it's documented, too!) but they'd be still locked out because they don't know the password.

But I'm quite paranoid.

 

[gemma-the-husky]

overall, though, password systems are non-trivial, i think

its not the same as windows, where you can just set a policy and the password will expire automatically

whether you use access security, or a manual user-table, you have to manage and control passwords yourself - so its not a five minute job to sort this out