Edward Posted August 15, 2012 Share Posted August 15, 2012 I am working on a forgot password page, there are two ways to go about this. 1. Send a new password to their email, so they can use it to sign back in and change password later. 2. Send a link to their email, in which the user can click to come back in be directed to the change password page. Which do you think is better and why? I saw some websites sending a link to your email like this to be sent back to the change password page: www.examplewebsite.com/reset_password/01b304a2-cb8d-4c4f-9468-8d3fbda3c0fe$username=exampleusername So what would that hash value be compared against, would we need a new column in our database user table for this? It seems to me that it would be a whole lot easier doing things the Larry way and just having a password sent directly to their account. Link to comment Share on other sites More sharing options...
HartleySan Posted August 15, 2012 Share Posted August 15, 2012 I personally prefer the link in the email that jumps straight to the password-change page. I prefer that because it's simpler and doesn't require me to write down/copy and paste a random password. That's just my preference though. Of course, something like that can be abused. For example, if you know that your friend has an account on a site that does that, you can put his email address in and make him reset his password. Not the end of the world, and I think rather unlikely, but all the same. 1 Link to comment Share on other sites More sharing options...
Larry Posted August 15, 2012 Share Posted August 15, 2012 I don't have strong feelings on this. In both cases, the goal is for the user to change the password anyway (i.e., go back to the site). 1 Link to comment Share on other sites More sharing options...
Edward Posted August 15, 2012 Author Share Posted August 15, 2012 I personally prefer the link in the email that jumps straight to the password-change page. I prefer that because it's simpler and doesn't require me to write down/copy and paste a random password. That's just my preference though. Of course, something like that can be abused. For example, if you know that you friend has an account on a site that does that, you can put his email address in and make him reset his password. Not the end of the world, and I think rather unlikely, but all the same. Thanks for both your comments but what about the hash value what could that be generated from possibly the current password? Link to comment Share on other sites More sharing options...
Antonio Conte Posted August 15, 2012 Share Posted August 15, 2012 You should just generate a random clear text password first. I would then mail this to the user. When this is done, run the hash function on the text password and save the hash to the DB. I'm working on creating this functionality for my own site right now. 1 Link to comment Share on other sites More sharing options...
HartleySan Posted August 15, 2012 Share Posted August 15, 2012 Ditto to what Antonio said. Link to comment Share on other sites More sharing options...
Antonio Conte Posted August 15, 2012 Share Posted August 15, 2012 I missed your hash question. I don't think that part of the URL is a password hash. I think it's more of a token the site should look for. When a user is requesting a new password, a random value is generated and the username, random value and probable a datetime "now" is inserted into a different table. The link is emailed to the user, and if the reset_password token is 01b304a2-cb8d-4c4f-9468-8d3fbda3c0fe (as in the link, the username is "exampleusername" (as in the link) and the current datetime is less than 10 minutes larger than the datime in the table, A match is found in the reset password token table. If this match is found, the user is allowed to change their password. This makes it more unlikely that someone should be able to change the password. NOTICE that I'm just guessing now. I don't really know if this is a good approach or not. Mind giving us your thoughts, Larry? After all, I'm working on the exact same thing myself. Link to comment Share on other sites More sharing options...
Edward Posted August 15, 2012 Author Share Posted August 15, 2012 I missed your hash question. I don't think that part of the URL is a password hash. I think it's more of a token the site should look for. When a user is requesting a new password, a random value is generated and the username, random value and probable a datetime "now" is inserted into a different table. The link is emailed to the user, and if the reset_password token is 01b304a2-cb8d-4c4f-9468-8d3fbda3c0fe (as in the link, the username is "exampleusername" (as in the link) and the current datetime is less than 10 minutes larger than the datime in the table, A match is found in the reset password token table. If this match is found, the user is allowed to change their password. This makes it more unlikely that someone should be able to change the password. NOTICE that I'm just guessing now. I don't really know if this is a good approach or not. Mind giving us your thoughts, Larry? After all, I'm working on the exact same thing myself. Yes i know its token but i just called it a hash. I was thinking of adding in a extra column in the users table for the password reset random token to go in. It would be good if we could use the activation code column but that part would already be set to NULL. I noticed on other sties that even when you requested your password you could still log in so they were definitely not using the activation code column. Antonio are using MVC framework for your site or building your own? I am going to work on a little more on my site then i will convert all over into my own mvc framework, which i am currently building. Link to comment Share on other sites More sharing options...
Edward Posted August 15, 2012 Author Share Posted August 15, 2012 I personally prefer the link in the email that jumps straight to the password-change page. I prefer that because it's simpler and doesn't require me to write down/copy and paste a random password. That's just my preference though. Of course, something like that can be abused. For example, if you know that your friend has an account on a site that does that, you can put his email address in and make him reset his password. Not the end of the world, and I think rather unlikely, but all the same. By the i have decided to use your method, i agree on what you are saying, copying and pasting a password you don't like is just not nice. And then you have 2nd factor of having to log in and find the password change section on the site we takes more time. Yes i am going with this method, thanks for helping me clear up my thoughts on this one. Its very important we give the user vip service. Link to comment Share on other sites More sharing options...
Edward Posted August 21, 2012 Author Share Posted August 21, 2012 I was looking more into this password reset token, either you could make a separate table to hold token values which would expire within a certain time. Or you could add a token for password reset into the users table. If you were going to create a token from the information of the user this would be unsafe and leave room for someone to try to figure out how the code was generated. So the safe way seems to be adding in another separate table for this and using md5 randomly generated tokens, or just adding an extra column to users. Anyone have any more idea's on this? Link to comment Share on other sites More sharing options...
Larry Posted August 22, 2012 Share Posted August 22, 2012 There's an argument to be made not to send a temporary password to users, although it is common. Check out this: http://crackstation.net/hashing-security.htm#faq Link to comment Share on other sites More sharing options...
Antonio Conte Posted August 23, 2012 Share Posted August 23, 2012 Very interesting. Bookmarked. Also looks like my guess about email tokens was pretty good. One argument though. The importance of keeping the data safe should affect your choice of hashing algorithm. I see some of these hashing functions has some many round times per hash creation that a page will take 4-5 (someone up to 20) seconds to render. Those won't make it for most people. Link to comment Share on other sites More sharing options...
Larry Posted August 23, 2012 Share Posted August 23, 2012 Yes, exactly. There's no one true security approach. The level of security needs to match the application. Link to comment Share on other sites More sharing options...
Recommended Posts