If a cognito user lost his confirmation email is unable to reset his password, or ask for resent if his is in "force_change_password" status, and no error is displayed to him.
Is there any known fix on that?
Doesn't completely solve my issue, but it does provide an error message to the user.
If you go to User Pool -> General Settings -> App clients -> under Prevent User Existence Errors -> change from enabled to legacy.
So when the user clicks on the forget password will see this error message "Could not reset password for the account, please contact support or try again".
If a user is in "force_change_password" it is often because you performed an Admin create user operation, where the user is then sent a temporary password to use. After using that temp password the user will be asked to set a new password.
If this is the password you are referring to you can perform admin create user again for the same user and set MessageAction to 'RESEND' [1].
"Set to "RESEND" to resend the invitation message to a user that already exists and reset the expiration limit on the user's account."
[1] https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html
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 would like to know which procedure should I take in the following situation:
A user register itself into the system and an email is sent to confirm the account (with the confirmation token).
But the user doesn't comfirm the account...
If later, the same user or another user try to register itself with the same email, should I:
Delete all the information about the first user, create an entirely new account and send a new email for validation?
Change the existing account by reseting the password and send an email with a new confirmation token?
Another suggestion?
In this scenario, I'd say that registering an account is like putting down a deposit. You've basically staked a claim to that user account. I would give the confirmation tokens an expiry time - say, three days or so. If a second user tries to register an account that conflicts, check whether the user it conflicts with is verified, and for unverified users, check whether their token is expired.
If there's a verified user with that name, tell them "sorry, that username is taken".
If there's a user who has yet to verify...
If their token is expired, then delete it all and give the new user the name, generating a new verification token for them.
If their token is still active, then the new user can't have the name. It's up to you whether you just say "that username is taken" or maybe let them know that it's not verified and may be up for grabs sometime soon. I'd probably avoid confusing the users with that much detail, and just say it's taken.
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.
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.