Password change: Best practice

Question

I'm writing Baby's First Web Application. My first task has been to set up an authentication system, which I think I've done okay on. I'm new to the whole thing, though, so:

When the user reports that he's forgotten his password, I e-mail him a temporary replacement password in plain text. It's perhaps not the most secure way to handle the situation, but it's how I do it for now. I do force him to change it at the next login, and the technique I use is to carry a "must-change" field in the database, set to true for users who've been sent the e-mail.

My question: Is a separate database column the best tactic under the circumstances, or is there something better I can do?

Answer 1

A separate column is quite reasonable.

Operating systems typically have a "password expiration timestamp" field which doubles as a "must change at next logon" flag simply by setting the timestamp to 0 (AKA January 1, 1970). Web sites do not usually have password expiration dates, in which case a plain boolean flag suffices.

Answer 2

I presume you are storing passwords hashed and salted. If not, do so. If so, you could store meta-data in the salt. E.g. the salt is [0-9a-z]{8}, but for temp passwords it is ____[0-9a-z]{4}. (before downvoting, people, read on!) The point in this, is that a separate field might get edited separately from the hash field. Of course that should never happen, but it can happen. (failing queries, moronic sysadmins, people who have discovered phpmyadmin and think they understand the system, etc) Keeping the "state" of the password in the salt, prevents such mayhem: on validation of the password, you will always be able to see that you validated against a temp password, and you will always be able to identify the user who needs to get a "enter new password" prompt.

Answer 3

My practice has always been to overload the email validation (where you send an email to the registrant to make sure that the registrant owns the address) to also function as a password reset mechanism. I use certain information about the user (username, id, email, and importantly, the current password hash in DB) to make a hash, which is included in a URL that's emailed to the user, at which point they can set a new password of their choosing.

That being said, the "best practice" vis-a-vis user authentication is 95% of the time to user a library that someone else has written and tested extensively. Just search Google for one that's appropriate for your framework.