Improved password protections
Short, concise description of the idea
Encrypt passwords, so they cannot be recovered; for lost passwords, retain a challenge/response question which, when answered successfully, generates a one-time password.
Full description of the idea
One-way encrypt all passwords for LJ, so that even if someone breaks into the site, they will have to brute-force stolen passwords to be able to use them. See the password setup on any Unix system for an example of this.
To allow a user to recover his password, when someone creates a new account, in addition to asking them for a username and password, also ask for a challenge-response question. You're probably familiar with some of these, such as a bank wanting your mother's maiden name for verification. Permit the user to write his own question, and provide an answer. For password recovery, ask the user that question; he must provide his answer *exactly* as he typed it on account creation. Upon successfully answering the question, generate a random password, which gets encrypted and replaces the existing encrypted password. Mail this random password to the user, and flag his account such that when he logs in, he *must* change his password before being able to do anything else.
An ordered list of benefits
No regularly-used passwords mailed to users.
Passwords are not immediately compromised even if the site is compromised. (However, with enough time and processor power on a brute-force attack, any encryption scheme can be broken.)
Passwords become known only to the user and people who the user has given the password to -- not even LJ staff knows the password.
If a black hat knows the answer to the challenge question, and tries to get the password reset, the black hat must also have taken over the user's email to be able to intercept the password.
While this mails a usable password in the clear, presumably the user requesting password recovery will be waiting for the password to arrive, and will act promptly to get in once the password does arrive, so the window for abuse will be much smaller than it is now.
An ordered list of problems/issues involved
Requires the user to remember the answer to the challenge to be able to do password recovery.
Requires that the password section of your user database have encryption enabled.
Requires that there be two additional database columns for each account, containing the challenge question and answer.
Requires the added step of choosing a challenge question and its answer for account creation, and the attendant UI changes to allow this.
Still mails a usable password in the clear.
Because of the flexible nature of the challenge answer, likely to be misspelled more often than a password, especially due to its rare use.
For the challenge answer to be useful, barring dictionary words and other bad password practices is impossible.
An organized list, or a few short paragraphs detailing suggestions for implementation
You'll need to add three columns to your user database, one for challenge question, one for the challenge answer, and a simple boolean for "password change required".
You'll need to encrypt the password column and the challenge answer column. (If you have actual, live techsupport people who will be able to help users who have lost their password and have forgotten the exact challenge answer, then the challenge answer should not be encrypted.)
The account creation UI will need to include text boxes for the challenge question and challenge answer. (Perhaps two for the answer, much the same as a password confirmation.) An alternate idea is to provide a pulldown menu of stock challenge questions, with "Other" being one of the options if the user wants to write his own.
The password recovery sequence should change to ask for the user's email address or username, which then produces that user's challenge question, with a text box for the user to type in his answer. With a correct answer, the user's password gets altered as described above.
Finally, you'll need to re-code the login sequence to require a password change when the "password change required" boolean is set. This would present the user with a password change page no matter where he tried to go on the site, until he changed his password -- at which point the "password change required" boolean gets cleared, and the user can go about his business.
Hope this is clear enough.