Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Password Encryption + change every 90 Days 1

Status
Not open for further replies.

fmrock

Programmer
Sep 5, 2006
510
0
0
US
Hey everyone,

I have a few sites built with Classic ASP. These are private intranet sites that are password protected.

I store the password as text in my users table. I am goaled to make the passwords more robust and have to have them change every 90 days. Not allowing them to reuse the same password again.

I also think I should encrypt the password in the database.

I have seen some stuff on MD5, but not sure if thats the way to go or not. Any advice, examples, or input would be great.

Thanks for your help.
 
1. Create a 2nd table called past_passwords with two fields

a. user_id
b. password_used

2. Add a password_created field in your user table

3. When someone logs in, check the current date against the password_created field, if it is older than 90 days, redirect them to a page to change it.

4. When they change their password, check it against the current password and all their previous passwords in the past_passwords table

5. If the new password was not found, add a new record to the past_passwords table with the user_id and current_password / update the users table with the new_password and set the password_create_date to now().




--------

GOOGLE is a great resource to find answers to questions like "how do i..."


--------
 
foxbox...what do you usually use for the password for the text you encrypt. Would you make this dynamic per user, or the same for all users in the system?
 
i will not reveil that here hahahaha.
plain text passwords in a table is very wrong.
With that RC4 script you have 1 function to encypher en to decypher. If you choose a long and strong password, i see no problem in having 1 encryption key
 
i see no problem in having 1 encryption key

further to this point, if you have a unique key for each user, you'll need to store that information somewhere (most likely in the db) which defeats the purpose..

UNLESS you calculate it by things like first letter of first name + last letter of last name + length of first name + length of last name so:

Bob Smith becomes BH35 and Susy Jane becomes SE44.

But if Susy marries Bob, she becomes Susy Smith and her key is not valid anymore.






--------

GOOGLE is a great resource to find answers to questions like "how do i..."


--------
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top