I am writing Baby's First Web Application. My first task is to setup an authentication system, that we think I have done okay on. I am a new comer to the entire factor, though, so:

Once the user reviews that he's forgotten his password, I e-mail him a brief alternative password in plain text. It's possibly not probably the most secure way to handle situation, but it is the way i get it done for the time being. I actually do pressure him to alter it in the next login, and also the technique I personally use would be to have a "must-change" area within the database, set to true for customers who had been sent the e-mail.

My question: Is really a separate database column the very best tactic underneath the conditions, or perhaps is there something better I'm able to do?

Another column is very reasonable.

Os's routinely have a "password expiration timestamp" area which doubles like a "must change at next logon" flag by simply setting the timestamp to (Also known as The month of january 1, 1970). Internet sites really don't have password expiration dates, by which situation an ordinary boolean flag suffices.

I presume you're storing passwords hashed and salted. Otherwise, achieve this. If that's the case, you can store meta-data within the salt. E.g. the salt is [0-9a-z]{8}, however for temp passwords it's ____[0-9a-z]{4}. (before downvoting, people, continue reading!) The purpose within this, is the fact that another area could easily get edited individually in the hash area. Obviously that should never happen, however it can happen. (failing queries, moronic sysadmins, those who have discovered phpmyadmin and think they comprehend the system, etc) Keeping the "condition" from the password within the salt, prevents such mayhem: on validation from the password, you'll always have the ability to observe that you validated against a temp password, and you'll always have the ability to identify the consumer who needs to obtain a "enter new password" prompt.

My practice happens to be to overload the e-mail validation (in which you send an e-mail towards the registrant to make certain the registrant is the owner of the address) also to be the password totally reset mechanism. I personally use certain details about the consumer (username, id, email, and importantly, the present password hash in DB) to create a hash, that is incorporated inside a URL that's e-mailed towards the user, after which they are able to set a brand new password of the selecting.

That being stated, the "best practice" vis-a-vis user authentication is 95% of times to user a library that another person has written and examined extensively. Just look Google for just one that's right for your framework.