Many lost password workflows usually result in a page which is reached by a temporary link emailed to the user. This link then takes them to a page that asks for a new password.
Upon entering the new password should a user be forced to logon manually, or should the password reset page authenticate the user automatically which would reduce the number of steps and thus complexity of the process for the end user?
I often encounter password reset pages that make me reset my password and then login which feels like I'm logging in twice for no good reason.
I quite like drupal's method: The user gets sent an email with a link in it which will log them on once; upon logging in with it they are given the opportunity to change their password.
I don't know of any significant advantage to forcing the user to re-enter the password that they just entered twice. If someone does, I'd be interested to hear about it.
You should make it auto login. Don't see why you would make the user login.
If it's because of bot protection, just add a captcha when the user logins using the link.
Related
I would like to ask some questions about password security. In my software the admin can create a new user setting the password and the username. I believe sending the password in plain text in an email is not a very good idea, so I’m thinking about sending a link that redirect the user to a page where they can set up their password. This link should expire after few hours as well. On my login form I’ve also have the option “forgot password” how can I prevent that a user doesn’t use it until they create the new password? How would you do it?
A password reset link is technically exactly the same as a registration link, both are relying on the "fact" that only the owner of the email address can read the link. So there is no reason to prevent a password reset when the user did not yet login.
The usual workflow is slightly different though, usually the user makes the first contact with the site and on the register page (s)he is asked to enter a password.
I'm in the middle of implementing "forgot password". my auth is via jwt access token. (user log in, gets an access token, sends it with the rest api calls).
so let's say the user which currently isn't logged in, click the "forgot password".
i create for him some hashed token, and then send him a mail.
if he will click it I'll decode, display him the change password, and create a new access token, like this is the main idea and all good.
My question is for this scenario:
user clicks forgot password, enter his mail, i send him a mail, but then instead of clicking the url and resetting, he logs in via his password.
should i let him log in? creating an access token and all good? while resetting the token from the sent mail (or is it still a valid token to reset the password with?)
display some error saying go to your mail and continue forgot password process?
my question is from security aspects, since maybe a user think his password was compromised, and then if i do let him in, then maybe someone who got the password (which isn't the user) can still log in /change password - while the original user goes to the mail and think he processed with the process.
i know it's maybe a rare race condition but i would like to avoid it.
(also, if i do let him in, and then he click the url from the mail which was already sent, should i reset it? in my scenario, maybe it's better not to reset? or if a user click twice "forgot password" should i create 2 different tokens, accepting only the later?)
ii realy would appreciate an advice, how to handle that scenarios, all forgot password related.
thanks.
Im not an Expert. This is just my opinion:
The "Forgot Password" funktionality should not render the old password unusable as someone else could invoke this process to prevent the owner of the acount from logging in.
It could take you quite some time to realize the email and would cause a lot of headdache.
When someone requests multiple emails in a short while they should all be functional. It happens often that the mail servers take their time and humans are not known for their patience so they click the button twice but use the first link arriving in their inbox.
This is all conserning usabilty.
Now to security:
The emails should also stay active when someone loggs in. As you mentioned a malicious actor could log in and otherwies prevent the owner from changing their password that way.
I think i get the whole password hashing and verifying login as I got it working with php. however I need an answer and some advise and I dont mean dont eat yellow snow!! :)
I want to store the passwords of users in a hashed format, however I have a need where by I need to be able to see or use given password so I can help the customer fix there issues as a technician.
Now passwords are first created by my system then issued to customer, however users have the choice to change their passwords if they so wish.
username is also created by system.
Now that being said:
I had 2 thoughts both of which I have no idea how to do so some pointer or an answer would be great.
idea 1:
is to have a button on my site to show only the technicians the user password on demand. so they can copy and paste to the site.
Idea 2:
I was also thinking that rather than see the password. I could have some way to transfer the password into the site to create an auto login into the website.
So technician would have a button that they press and the password is sent to the site to auto login with the hashed password.
Thanks in advance.
To give technicians access to a user account, there is no need to know the users plaintext passwords. It is the job of your application to restrict access, so you can create an admin role which is able to impersonate a user.
Making passwords recoverable weakens the security of your site immensly.
Is it safe to login user automatically after registration?
User fills registration form, some info message is sent to his mailbox, and what then:
User redirected to login page asking him for credentials;
OR
User auto-logins as his newly created user?
I feel something not safe enough in auto-login, but can't figure it out!
If they just filled out the login information and you're not concerned about confirming that the email address is legit, then there shouldn't be a problem just logging them in directly.
However, you open yourself up to people/bots creating bogus accounts (at least ones without legitimate email addresses). If you're concerned about that (not sure it this is a public facing app or intranet, etc) then you should at least verify the email address by sending a link with a guid or some identifier that you can track back. Then you can let them log-in once they are confirmed.
You could also just tie it to their StackExchange/Facebook/OpenID/etc account and not make users fill out yet another form and worry about maintaining all that information.
They should need to login. Also the confirmation email should not contain their password. If they managed to give you the wrong email address and you automatically log them in then someone else has access to their account now. This holds even if you have them type their email address twice. Sometimes people make the same mistake twice in a row.
It can be safe to auto login if the user already has an active session as the correct user during the confirmation step. If you think about it, it's not actually "automatically logging them in" but simply keeping them logged in as they was before.
User registers
Keep a session identifying the user
User navigates to the confirmation page (linked in email)
You activate the account
During all that time, there was no reason to end the session. The only reason you would want to end the session (or not create one in the first place) is if your permissions are not properly set to allow someone to login / create a session without giving them higher privileges than an unregistered user.
Now, be sure not to automatically identify the user as X simply because this person navigated to the confirmation page of user X. If a user navigates to this page but does not already have a session open, do not assume he knows the password.
We're setting up a feature to enable users to reset their password when they can't get access ot their account. We ask for their email address (which they use for logging into the site), send them an email with a unique link.
The questions are:
Should the link expire on first-click or should the link expire on first-use (ie, they reset their password successfully)?
Should the link have 24 hour validity (or something similar)?
Should the user be logged in after he clicks that link?
The link should expire after the password is changed. If you expired the link on the first click this can cause problems. Let's say I've got bad internet connection, and the page didn't load completely to my browser. I reload the page and it says link is expired. I wouldn't be happy user to see that.
Yes, you should limit the link to some reasonable time. 24 hours looks reasonable enough. If you don't limit the link lifetime, first of all you will have to store the generated id forever, secondly the longer you keep this link active the higher probability that link will be stolen by attacker, which will lead to stealing account.
You should let user in only after user changes his/her password. If you just log them in, they probably will decide that they don't have to change password anymore. This way they can keep logging into the system forever without ever changing/knowing their password.
The link should expire after they have reset their password successfully. If somehow the user ended up needing guidance on a password reset and wanted to return later, they should be able to.
That being said the reset should expire eventually, 48 hours?
Yes they should be logged in after a password reset, otherwise there is another frustrating step in the way of your user doing what they came to do on your site.