Well, im starting to write the installation routine, so we need to decide on a way to encrypt passwords.
We have three options:
1) Simple md5 hash comparison.
PROS: Most Secure Option
CONS: Cant retrieve lost passwords.
2) Plaintext password comparison.
PROS: Easily retrieve lost passwords.
CONS: Not secure, anyone with access to DB has passwords.
3) My idea for a password system:
- Starting password assigned at creation of account, and md5 hash recorded in the database.
- If password is lost, can ask to have a new password asssigned. System will send an email to the email address of the account with an account activation code. The next time they sign in, they use this activation code as their password. Then, the system will prompt them for a new password. OPTIONAL: We could have a secret question/answer before sending the activation code.
This idea was a spur of the moment idea, but I believe it is usable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know that PHP has the crypt() function, that does one-way DES encryption ... I use it in a system now. It also doesn't support recovering the password, but between SSL and crypt() (or whatever MD5-hash system) we should be able to handle password protection.
Frankly, whatever way we go, I vote that we store non-recoverable passwords in the database, and offer some kind of alternate identity-proof system for generating new passwords. That seems like 'best practice' posture.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-08-20
Yes, the identity system I think we will use is this:
1) User clicks lost password.
2) User receives secret question.
3) User answers secret question.
4) Activation code is sent to users email address.
5) User logs in with username and BLANK password.
6) System prompts user for activation code, (unless no activation code stored in DB, in which case standard "you must provide a password" message).
7) User enters activation code and new password, and answers secret question again.
8) The new password is saved, and activation code is cleared from the database.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-08-20
This way passwords are never outputted to the screen, and we have as much identity verification as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, im starting to write the installation routine, so we need to decide on a way to encrypt passwords.
We have three options:
1) Simple md5 hash comparison.
PROS: Most Secure Option
CONS: Cant retrieve lost passwords.
2) Plaintext password comparison.
PROS: Easily retrieve lost passwords.
CONS: Not secure, anyone with access to DB has passwords.
3) My idea for a password system:
- Starting password assigned at creation of account, and md5 hash recorded in the database.
- If password is lost, can ask to have a new password asssigned. System will send an email to the email address of the account with an account activation code. The next time they sign in, they use this activation code as their password. Then, the system will prompt them for a new password. OPTIONAL: We could have a secret question/answer before sending the activation code.
This idea was a spur of the moment idea, but I believe it is usable.
3) Seems the best plan...though we need to make sure that it can work without revealing passwords.
I know that PHP has the crypt() function, that does one-way DES encryption ... I use it in a system now. It also doesn't support recovering the password, but between SSL and crypt() (or whatever MD5-hash system) we should be able to handle password protection.
Frankly, whatever way we go, I vote that we store non-recoverable passwords in the database, and offer some kind of alternate identity-proof system for generating new passwords. That seems like 'best practice' posture.
Yes, the identity system I think we will use is this:
1) User clicks lost password.
2) User receives secret question.
3) User answers secret question.
4) Activation code is sent to users email address.
5) User logs in with username and BLANK password.
6) System prompts user for activation code, (unless no activation code stored in DB, in which case standard "you must provide a password" message).
7) User enters activation code and new password, and answers secret question again.
8) The new password is saved, and activation code is cleared from the database.
This way passwords are never outputted to the screen, and we have as much identity verification as possible.