Password that changes according to month

[dixie]

I want to have a password that will change for each month. If I had a table
with a field of 'Month' with the number of the month and another field
called 'Password' that had twelve records. What would be the best way of
looking at the current date and then, if it was say February, picking the
password that was against the number 2 in the Month field.

dixie

[jimfortune]

dixie wrote:

I want to have a password that will change for each month. If I had a table with a field of 'Month' with the number of the month and another field called 'Password' that had twelve records. What would be the best way of looking at the current date and then, if it was say February, picking the password that was against the number 2 in the Month field.

dixie

tblP
MonthID P
1 MLKJr
2 BMyValentine
3 bean239
4 prlfls
5 mmmysdy
6 dddysdy
7 ahatfoj
8 nohldy
9 tmstrs
10 gstsngblns
11 trkygblr
12 ntvty

SELECT P FROM tblP IN 'G:\HiddenDirectory\P.mdb' WHERE MonthID =
Month(Now());

This may not be the best way but it should work. Don't use Month for a
field name since it's a reserved word. MonthID is of type Long.
James A. Fortune

[dixie]

I see you use a different database in a hidden folder to put the passwords
in. What about just a hidden table say USysPW?

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

dixie wrote:

I want to have a password that will change for each month. If I had

a table

with a field of 'Month' with the number of the month and another

field

called 'Password' that had twelve records. What would be the best

way of

looking at the current date and then, if it was say February, picking

the

password that was against the number 2 in the Month field.

dixie

tblP
MonthID P
1 MLKJr
2 BMyValentine
3 bean239
4 prlfls
5 mmmysdy
6 dddysdy
7 ahatfoj
8 nohldy
9 tmstrs
10 gstsngblns
11 trkygblr
12 ntvty

SELECT P FROM tblP IN 'G:\HiddenDirectory\P.mdb' WHERE MonthID =
Month(Now());

This may not be the best way but it should work. Don't use Month for a
field name since it's a reserved word. MonthID is of type Long.
James A. Fortune

[dixie]

I guess my previous post was just a rhetorical question, as both would work.
Thanks for your help james. It is just what I needed.

dixie

"dixie" <di***@dogmail.com> wrote in message
news:41********@duster.adelaide.on.net...

I see you use a different database in a hidden folder to put the passwords
in. What about just a hidden table say USysPW?

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

dixie wrote:

I want to have a password that will change for each month. If I had

a table

with a field of 'Month' with the number of the month and another

field

called 'Password' that had twelve records. What would be the best

way of

looking at the current date and then, if it was say February, picking

the

password that was against the number 2 in the Month field.

dixie

tblP
MonthID P
1 MLKJr
2 BMyValentine
3 bean239
4 prlfls
5 mmmysdy
6 dddysdy
7 ahatfoj
8 nohldy
9 tmstrs
10 gstsngblns
11 trkygblr
12 ntvty

SELECT P FROM tblP IN 'G:\HiddenDirectory\P.mdb' WHERE MonthID =
Month(Now());

This may not be the best way but it should work. Don't use Month for a
field name since it's a reserved word. MonthID is of type Long.
James A. Fortune

[jimfortune]

dixie wrote:

I guess my previous post was just a rhetorical question, as both would work. Thanks for your help james. It is just what I needed.

dixie

I like your idea. Would an .mde effectively bury the password
information to the user?

James A. Fortune

[dixie]

I am doing it in an mde file and I have locked the program so you can't hold
the shift key down and open it. It is as close to secure as I can make it
without applying Access security which I don't want to do. I am going to
try to extend the idea to more than 12 possible passwords by using the
datediff function - I haven't quite got around to it yet, but I am going to
look at how I might do it. I'm thinking 365 possible passwords so that the
password automatically changes each day.
DateDiff("d",[StartDate],[EndDate]) will generate the number of the day and
I will somehow make this lookup a password. for that day. I am sure I can
use something like your last suggestion.

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

dixie wrote:

I guess my previous post was just a rhetorical question, as both

would work.

Thanks for your help james. It is just what I needed.

dixie

I like your idea. Would an .mde effectively bury the password
information to the user?

James A. Fortune

[jimfortune]

dixie wrote:

I am doing it in an mde file and I have locked the program so you can't hold the shift key down and open it. It is as close to secure as I can make it without applying Access security which I don't want to do. I am going to try to extend the idea to more than 12 possible passwords by using the datediff function - I haven't quite got around to it yet, but I am going to look at how I might do it. I'm thinking 365 possible passwords so that the password automatically changes each day.
DateDiff("d",[StartDate],[EndDate]) will generate the number of the day and I will somehow make this lookup a password. for that day. I am sure I can use something like your last suggestion.

dixie

I've applied Access security before and completely understand why you
don't want to use it unless it's absolutely necessary. Format(Now(),
"y") will give a number from 1 to 366 (leap year). Also, when you
create your password table, leave the ID field off until the end. Then
apply it as an autonumber, save, and then change it to Long and to a
primary key. That way you don't have to type in all those pesky
numbers. I remember that you once dealt with importing tables from
other databases so you have probably considered this possibility with
the mde.

James A. Fortune

[dixie]

Thanks James, that one is better still, as I only had 12 passwords
originally. I have applied your expression to a table with 366 passwords
that are then concatenated with other information to give a daily password.
I also used Left$ and Right$ on them so that if anyone ever finds the table,
it still wont give them the password. The only other thing I will look at
here is that at the end of the year, to somehow scramble the passwords so
the passwords for next year are different for the same day than they were
this year.

Thankyou for your helpful ideas.

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

dixie wrote:

I am doing it in an mde file and I have locked the program so you

can't hold

the shift key down and open it. It is as close to secure as I can

make it

without applying Access security which I don't want to do. I am

going to

try to extend the idea to more than 12 possible passwords by using

the

datediff function - I haven't quite got around to it yet, but I am

going to

look at how I might do it. I'm thinking 365 possible passwords so

that the

password automatically changes each day.
DateDiff("d",[StartDate],[EndDate]) will generate the number of the

day and

I will somehow make this lookup a password. for that day. I am sure

I can

use something like your last suggestion.

dixie

I've applied Access security before and completely understand why you
don't want to use it unless it's absolutely necessary. Format(Now(),
"y") will give a number from 1 to 366 (leap year). Also, when you
create your password table, leave the ID field off until the end. Then
apply it as an autonumber, save, and then change it to Long and to a
primary key. That way you don't have to type in all those pesky
numbers. I remember that you once dealt with importing tables from
other databases so you have probably considered this possibility with
the mde.

James A. Fortune

[jimfortune]

dixie wrote:

..
I also used Left$ and Right$ on them so that if anyone ever finds the table, it still wont give them the password. The only other thing I will look at here is that at the end of the year, to somehow scramble the passwords so the passwords for next year are different for the same day than they were this year.

Thats's a very clever idea, Dixie. You could keep the same passwords
the next year and vary whether Right or Left is used and vary how many
characters are used. Mid(s) would really mess with their minds :-).
James A. Fortune

[dixie]

Actually, just concatenating the 1st and last digits of the year into the
password somewhere would work. Mine already have numbers in then, so nobody
would guess what they represented. Voila, rotating daily passwords that are
different from year to year.

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

dixie wrote:

..
I also used Left$ and Right$ on them so that if anyone ever finds the

table,

it still wont give them the password. The only other thing I will

look at

here is that at the end of the year, to somehow scramble the

passwords so

the passwords for next year are different for the same day than they

were

this year.

Thats's a very clever idea, Dixie. You could keep the same passwords
the next year and vary whether Right or Left is used and vary how many
characters are used. Mid(s) would really mess with their minds :-).
James A. Fortune

[dixie]

Well actually, using the 1st number of the year would be stupid as it is
going to be a 2 for the next 995 years :-)

dixie

"dixie" <di***@dogmail.com> wrote in message
news:42********@duster.adelaide.on.net...

Actually, just concatenating the 1st and last digits of the year into the
password somewhere would work. Mine already have numbers in then, so
nobody would guess what they represented. Voila, rotating daily passwords
that are different from year to year.

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

dixie wrote:

..
I also used Left$ and Right$ on them so that if anyone ever finds the

table,

it still wont give them the password. The only other thing I will

look at

here is that at the end of the year, to somehow scramble the

passwords so

the passwords for next year are different for the same day than they

were

this year.

Thats's a very clever idea, Dixie. You could keep the same passwords
the next year and vary whether Right or Left is used and vary how many
characters are used. Mid(s) would really mess with their minds :-).
James A. Fortune

[jimfortune]

dixie wrote:

Actually, just concatenating the 1st and last digits of the year into the password somewhere would work. Mine already have numbers in then, so nobody would guess what they represented. Voila, rotating daily passwords that are different from year to year.

dixie

Thank you for your helpful ideas also. BTW, bean239 is from a dumb St.
Patrick's Day joke. Why don't Irishmen eat more that 239 beans on St.
Patrick's day? Too farty (groan).

JAF

[Nicolas Noakes]

Prehaps i am missing something, but what is the point of having a
rotating password? How does the user know what password to use, or
remember all of them? If it is an installer/licensing solution, you
can't just scramble all 366 passwords around every year - you as the
auther also need to know which password to use.

Nicolas

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[dixie]

Thankyou James, you are too kind. I often have what I consider are good
ideas, but often lack the programming skill to put them into code. I am
slowly learning though and this news group has been a terrific help to my
tardy development.

dixie

<ji********@compumarc.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Dixie,

You certainly are creative. Feel free to share any innovations you
have with the rest of us. Often users are not sophisticated or will be
fired if they tamper with things they shouldn't so the company doesn't
mind a little 'openness' in the implementation. Security to prevent
employees from getting at things and security to prevent hackers from
getting at things are different ballgames. I need to use less cliches.
Washington would cease to function without them.

James A. Fortune