I have a flask application running on a production environment, and one of the user requested a password reset, which sent out an email to them with a link back to the site for resetting the password.
That email got shared with a third-party probably, and the link got exposed. Now the reset request is being spammed from multiple IP addresses. There is a timer I set using the SECURITY_RESET_PASSWORD_WITHIN config parameter to 30 mins and I can see that it does work as intended, the link is invalidated and throws an error saying the link has expired.
But the default behavior of the Flask-Security package is to re-send the reset email to the user if the token has expired when doing a GET request to the reset page with the expired token. So someone can keep spamming that expired link using
GET /reset/token_id
and the user keeps getting sent reset emails.
What is the correct way to handle this situation?
Once the user changes their password, those tokens should be viewed as 'invalid' and then not send emails any more.
Related
So I am making a website with account activation when registering and this works fine. But the part where I have to send email to reset password doesn't. If I turn the email backend to 'console', It works fine. In the console I get the message with the token link to reset the password. When I turn the email backend to 'smtp' it just doesnt work and I get a long error after I submit the email that the message has to be sent on. Also I don't have a pasword reset view. I don't know if that is the problem.email_SettingsPassword reset formspasswordreset_confirm_htmlpassword_reset_Form_htmlpassword_reset_urlserrorerror location
I tried moddeling a Password reset view. I don't know if the view was right or this does not solve the problem. Also I googled this error but I didnt find something useful. Tried to change some urls.
Good afternoon,
I'm using Cognito hosted ui with some admin methods to configure my authentication flow.
I'd like my users to have the possibility to reset their own passwords using the Forgot your password? link on the hosted ui which works fine. But an administrator should also be able to force reset any user's password.
For that I use the adminResetUserPassword https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html which works fine excepts that it sends a first verification code by email and then when the users returns on the hosted ui page and enters his (right but old) password, he is redirected to /forgotPassword page, is prompted to enter his username (email) and then receive a second verification code.
The first one is then expired. I find it a bit confusing for the user to receive the verification code twice and the first one is never used.
I reckon I need to find a way to redirect my users to /confirmPassword instead of /forgotPassword which re-triggers a new verification code. Is there a way to do this?
Many thanks,
After validating the user, I'm sending out the access token to the user's email, along with the link to come back to the same page.
[![Access Token email][1]][1]
[1]: https://i.stack.imgur.com/OWezf.png
This works well when the user opens the email in the same browser in which he was previously validated, but if he opens the email on his mobile or some other browser and then clicks on the link, he is taken back to the validation page to enter his user details again.
How can I maintain the same session across multiple platforms in Django? I know methods exist that can accomplish that. For example, an API can take an encrypted request id as a parameter, which will be included as a token in the access code email link to the landing page. The API will decrypt the encrypted request id and then return the payload back, associated with the same request id, and the data can then be used on the front end to identify the user and resume the access-code verification step.
But I don't know how to implement that or if there is a better solution.
We have React Native app that uses Cognito for authentication. We would like to prevent the same user ID from logging in simultaneously from multiple devices.
We were hopefully that we could use a Cognito pre-authentication trigger for this. Unfortunately it seems that we can't just call globalSignOut for the user since that wouldn't invalidate tokens that have already been issued and are currently active (see https://github.com/amazon-archives/amazon-cognito-identity-js/issues/21#issuecomment-331472144).
The other idea was to reject the login if the user is logged in elsewhere. But we can't see a reliable way to tell whether the user is already logged in. We can see if there are valid tokens issued for that user but not if they are currently associated with an active session.
We also thought of maintaining our own DB of active sessions but there is no sign-out trigger so we wouldn't know when to remove a session from the DB.
You can use a token authentication system,
Issue a brand new token for each login, and check for available tokens.
if any token is available for the user that means He/She is logged in some other device, for this case you can prompt user that You are logged in other device.. are you sure you want to log out from that device ? and after clicking yes, you can clear all tokens for that user. And issue a brand new token.
AUTO LOGOUT : this token should be passed all over the back-end i.e. in headers of each and every API call token should be there... and should be checked before doing anything in back-end. if token is not available then throw 401. In your app if any API throws 401 then it means user is UNAUTHORIZED and should be logged out.
or
your app should be listening to one socket that responds to log out when it receives a message of same. so whenever your user logs in, a logout message will be passed across sockets and appropriate device with some token id or unique id will get that message and will log out a particular user from all other devices.
or
have a notification receiver which will be used to log out whenever necessary same as socket.
Reading the link you provided the API token / session system seems being faulty by design since long time already.
So without an own token-system inside cognito you won't have reliable results probably, at least in the current state of the system (as the repository is archived it won't be developed further by the owner).
What I propose is an own field in the database-table for users where each login is honored with an own token. A second own field in the same table with a timestamp, where the last access is saved.
If last access is older than a predefined time of 30, 60 or 120 minutes any user gets logged out.
If the last access is younger than the time-limit then the login-mask has to provide a random access token which is compared with that in the database:
- if the access-token in the database is too old for an active session, or just no access-token is stored, then access can be granted which means login is successful.
- the comparison of the current time with the time-stamp saved in the database is for cases where users never have been logged out by purpose but just by being disconnected or passive. I think this case will happen regularly, so it's no exception.
- logging out by click on a button should destroy the access-token in the database, so that the user can immediately login from any device, even from another one then before.
- if there exists a valid access-token in the database then no new access will be granted and the user should get shown a message that he has to sign out first at another login.
- The access-token could be stored together with a third own field for the session-id to make it more reliable and safe. On logout that session-token-field can be cleared too. The session-token can be copied from the global session if required to be saved in the user-record.
- Any checks are only done on login, tokens never have to be included on every page.
- On active logout the token(s) have to be destroyed to allow a direct login again, else the users had to wait till the max. age of the time-limit is reached to login again - at least on another device then before.
As the login itself is currently done independent from the check that has to be implemented, it would be possible to leave the new access-token completely away but use only the session-id as that differs on any device and browser. But perhaps there exists a situation where one of session-id and access-token can change but the other one not - I don't think so but perhaps I missed something in my considerations.
If you provide the access-token on every page like proposed by #Jadeep Galani or in a cookie - beside the corresponding check - you also can offer a button to sign out from all devices. This would enable the users to change login any time even without logging out at the last used device. Without access-token on every page or in a cookie this general logout-function solution is not possible as else access is only checked on login but not on all pages.
A general question is if it's still worth it to rely on the buggy cognito for login or just replace it completely by an own solution. You even could implement the desired authentication in your site in form of a wrapper-class and the concrete login-system could be replaced without changing that implementation.
You can use the UUID of the device to identify whether it is the same user. Add a UUID to each request header to record it in the DB, and then you can do what you want.
I am following this guide to allow the users to reset the password using email. The problem is when the user requests "password reset link" for multiple times, the old links generated are not invalidated. (Password can be reset using either the latest link or old links).
Is there any parameter I can set to invalidate the old links?
There is a property file called identity-mgt.properties which you can find in the /repository/conf/identity/ directory.
In this property file, there is a property called Notification.Expire.Time which you could use to set the confirmation code expire time in munites.
Notification.Expire.Time denotes the expiration time of the confirmation code. Even in a notification recovery scenario a confirmation code is generated. If notification is done via email, the link sent to the user for verification will include the confirmation code. Therefore, once the user clicks that link, the confirmation code will be verified. Thus, you can use this property to validate the link.
Currently, generated confirmation codes will invalidate only once user change his password successfully. So as you have mentioned user will be able to recover his password using any confirmation code he has retrieved. And when user successfully change the password, all the confirmation codes generated before that would be invalidated. This is the default behaviour for now and we don't have a configuration to change that.