time limited passwords

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I hope this is possible.....
Is there a way to set up a 30 day password that will automatically change to
a new password after the 30 days has expired? To protect my database from
people leaving etc.
 
Hi.
Is there a way to set up a 30 day password that will automatically change to
a new password after the 30 days has expired?
Click to expand...

Yes, but it's not a built-in feature. You could write a VBA procedure that
checks your user-defined table for the last date the password changed. If 30
days has expired since that date, then the user is prompted for a new
password. If the password is not changed, then the database closes. When
the password is successfully changed, the current date is stored in the table
and the application continues as normal. Each time the database is opened,
this VBA procedure would run, checking to see whether 30 or more days has
passed since the password was last changed.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. (Only "Answers" have green
check-marks.) Remember that the best answers are often given to those who
have a history of rewarding the contributors who have taken the time to
answer questions correctly.
 
That only takes care of the problem if they are still on the premises...and
should be done anyway. However, if they've copied the database and work
group file and brought it home, they'd still have access. So, you'd need
something to address that potential problem.
 
True. But my reading of the OPs words, does not give me confidence
that that is the situation he has in mind (evil user copies workgroup
file). I suspect there is some chance that he does not know you *can*
delete a user!

Cheers,
TC
 
Thanks for the help, however I'm not sure I was clear enough on the problem.
Basically the program may be used on multiple sites so I would like to
incorperate a feature that means that the password automatically changes
every 30 days, so I can issue the users I want to continue using the system
with the new password that access would automatically have programmed into it
somehow.

Any help gratefully received
 
rugby............where's Johnny? said:
Thanks for the help, however I'm not sure I was clear enough on the
problem. Basically the program may be used on multiple sites so I
would like to incorperate a feature that means that the password
automatically changes every 30 days, so I can issue the users I want
to continue using the system with the new password that access would
automatically have programmed into it somehow.

Any help gratefully received
Click to expand...

If you can design an algorythm that creates password strings and in that
algorythm include the month from the current system date then you can make such
a password only function during that month.

One of my field apps has an "Admin Tools" area where certain things can be
back-doored. I have them use this area when we are doing over-the-phone
troubleshooting for certain problems in the app. Over the phone I give them a
password that allows them into the tools and that password changes every day.
Making a password that changed weekly, monthly etc., could easily be
accomplished with a few changes to my function.

Is it hack-proof? Probably not. Someone who was exposed to three or more of my
passwords and knew the date that they were generated could likely
reverse-engineer the algorythm, but for the target group of my users it is more
than adequate.
 
So, this is like an ongoing registration process? Every 30 days, each
person's password changes automagically. *You* know what the new
password is, but they do not. If you send them the new password, they
can keep using the system. But if you don't, they can't. Correct?

This would be quite easy if each site was linked to a common workgroup
file. You could easily write a program to update the passwords in that
file, every 30 days. (Or preferably, to delete the users who you no
longer wish to allow.) But it's a bit harder if each site has a
physically seperate copy of the workgroup file.

Assuming the latter, one "el cheapo" way would be to have the databases
startup code, check the creation date-time stamp of the workgroup file.
If it is more than 30 days old, say "You need a new security file!",
and quit the application. Very crude - trivial to hack - but maybe it
would do for your purpose. Every 30 days, you'd send each site a new
copy of the workgroup file, with the appropriate users *retained or
deleted*. Then, you wouldn't need to change their passwords, at all.

Remember that a simple effort will keep 99% of people out. *No amount*
of extra effort, will keep the remaining 1% out.

HTH,
TC
 
Thanks Rick and TC,

Probably about to show my limits here but algorythms I've never done before.
The suggestion from TC is great. The only problem is that each location has
its own unique database records, so I can't replace their database as they
would lose thier customer records, as they are the only ones with them. Hence
the idea of a self creating password that can easily be emailed... or have I
not understood your suggestion?

Anyway, I really appreciate the help and time you guys have spent.

Thanks

NB Johnny didn't arrive in time for the 6 nations, hopefully the lions will
roar.
 
rugby............where's Johnny? wrote:

(snip)
The only problem is that each location has
its own unique database records, so I can't
replace their database as they would lose
thier customer records
Click to expand...

Erm, the usernames and passwords are not stored in the database! They
are stored in a seperate file called the workgroup information file.
I'm not sure how you could have secured your database successfully,
without knowing that. The first step in securing a database properly,
is to create a new workgroup information file. Did you do that?

HTH,
TC
 
Er, come to think of it: are you referring to a *user level* password
(which asks for a username *and* password), or a *database* level
password (which only asks for a password - not a username)?

TC
(off for the day)
 
Right, I see, yes I have done that, just didn't realise they were called
workgroup info files. So is there a way to set up these files to expire after
30 days and require a new one that can be sent to a user with the appropriate
new password?

thanks for the help by the way.
 
rugby............where's Johnny? wrote:
(snip)
So is there a way to set up these files to expire after
30 days and require a new one that can be sent to a user with the appropriate
new password?
Click to expand...


Refer to previous post describing one "el cheapo" way.

HTH,
TC
 
Hi TC

Please can you help me with this?

How, exactly, do you do the el cheapo way. I am totally self taught at this
and I just can't seem to get the main MDB database to look at the workgroup
file as you suggested. The El cheapo way seems to be the exact thing I would
like to put into my project but I am not sure what code is needed to achieve
it.

Once again thanks in advance for any help you can give.
 
Rugby, the method I suggested is very crude & easy to hack. But if you
wanted to try it, here's what you'd do.

1. Write a standard module containing the following function:

public function Startup()
msgbox "STARTED!"
end function

2. Use Tools : Startup to define that function as the startup function
of the database. (I've forgotten exactly what the field is caled on the
screen.)

3. Close then re-open the database. Make sure the message appears. If
it doesn't you've done something wrong.

4. Now replace the MsgBox statement with the following code:

if XXXXX(dbengine.systemdb) - date() > 30 then
msgbox "sorry, you need a new security file"
application.quit
endf

5. Replace XXXXX (above) with the name of the function that returns the
creation date/time of the specified file. I can't remember what that
is, and I don't have Access here to check.

Now the message should appear when you start the database & the
workgroup information file is more than 30 days old.

As I said, that method is crude, and easy to hack - but maybe it would
do for your purpose.

If you still can't work it out from here, I recommend that you get a
book on Access programming, so you can follow some structured examples.
My concern is, that at present, you can not really make an informed
decision between the "el cheapo" method suggested above, and the other
ways of doing this.

Good luck!
TC
 
There's one called the Access Developers Handbook. I've not read it
myself, but it's often mentioned favourably. Google on Access
Developers Handbook for suppliers & reviews etc.

Cheers,
TC
 
Back
Top