I need help in coding a Login page. The user can only use that current password after 10 iterations of different passwords. Example if my password is dog. I cannot use that passsword again until after 10 other different passwords. I need a starting point with some code. I would appreciate anyone's help.
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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Password Iteration Problem?
- Thread starter bmann
- Start date
assuming you already have a use/login table with username and password.
1. create an archive table to store previous username, password combinations.
2. as a new username/password combination is created update the login table and append the record to the archive table. then delete the 11th entry for the user (the archive table should have no more than 10 entries per user)
4. when the user attempts to create a password verify the password does not exist for that user in the archive table.
also keep in mind the stored values should be seeded and hashed.
that's the approach I would take. as for the implementation details. there are plenty of examples online about the various logic parts. all you need to do is tie them together.
Jason Meckley
Programmer
faq855-7190
faq732-7259
1. create an archive table to store previous username, password combinations.
2. as a new username/password combination is created update the login table and append the record to the archive table. then delete the 11th entry for the user (the archive table should have no more than 10 entries per user)
4. when the user attempts to create a password verify the password does not exist for that user in the archive table.
also keep in mind the stored values should be seeded and hashed.
that's the approach I would take. as for the implementation details. there are plenty of examples online about the various logic parts. all you need to do is tie them together.
Jason Meckley
Programmer
faq855-7190
faq732-7259
- Thread starter
- #3
possible searches to get started
salt hash password
asp.net authentication
asp.net forms authentication
customize (or override) asp.net forms authentication
ado.net code samples *
*assumes you are saving the audit history to a relational database.
chances are your best bet is to subclass the existing forms authentication. added the logic which validates the password has not been used in the last 10 changes.
there will not be a specific example about 10 password iterations.
1. 10 is arbitrary. it could just as easily be 5, 50, 500
2. where you store the password is independent of the logic required to validate the password. you could store user credentials anywhere. most common is a relational database, but that is only one option for persistent storage.
3. user passwords is just one specific context you can iterate over any collection.
i would probably take this approach if i was getting started:
1. get forms authentication working
2. get forms authentication working with a salted/hashed password. i don't think it does this by default.
3. introduce the audit table to store the recent history (last 10 salted/hashed passwords).
4. incorporate the audit query as part of validation.
Jason Meckley
Programmer
faq855-7190
faq732-7259
salt hash password
asp.net authentication
asp.net forms authentication
customize (or override) asp.net forms authentication
ado.net code samples *
*assumes you are saving the audit history to a relational database.
chances are your best bet is to subclass the existing forms authentication. added the logic which validates the password has not been used in the last 10 changes.
there will not be a specific example about 10 password iterations.
1. 10 is arbitrary. it could just as easily be 5, 50, 500
2. where you store the password is independent of the logic required to validate the password. you could store user credentials anywhere. most common is a relational database, but that is only one option for persistent storage.
3. user passwords is just one specific context you can iterate over any collection.
i would probably take this approach if i was getting started:
1. get forms authentication working
2. get forms authentication working with a salted/hashed password. i don't think it does this by default.
3. introduce the audit table to store the recent history (last 10 salted/hashed passwords).
4. incorporate the audit query as part of validation.
Jason Meckley
Programmer
faq855-7190
faq732-7259
- Status