Skip to content

API to check if tokens are still valid, without changing password #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
eddyystop opened this issue Nov 22, 2016 · 4 comments
Closed

Comments

@eddyystop
Copy link
Collaborator

eddyystop commented Nov 22, 2016

eddyystop/feathers-service-verify-reset#21

Hello,

First of all this is an awesome lib! Thanks for doing this 🍕
So we have a use case where we reset the password by using:

verifyReset.create({
      action: 'sendResetPwd',
      value: email,
      notifierOptions: {
        transport: 'email',
        route: url
      }
    }, {})
    .then(() => this.context.router.push('/session/forgotten-password/sent'))
    .catch(() => this.context.router.push('/session/forgotten-password/error'));

Once user has received the email and navigated to the link within (example: http://localhost:3000/session/forgotten-password/reset/8dce33f3a30ad1df0e3d4676fe7d91) we want to check whether user.resetToken is still valid.

Is there a method or plan to do this through verifyReset?

Edit: I can always make myself a simple endpoint for checking this, however I think it would be an awesome add-on to the lib.

Thank you,

@shawnlauzon
Copy link

My product team had this same request. We are using a 5 digit SMS code to reset, and I had believed that this function was intentionally left out because hackers could brute force the token. Is this the case, or is it a feature which could be provided?

@eddyystop
Copy link
Collaborator Author

A concern about security for short numeric tokens is the main reason for not implementing this (yet?). A rate limiter would be advisable that limited the retries per userId, perhaps once every few seconds. That, in addition, introduces state restricted to a single instance.

Furthermore a function to check this without a rate limiter is not difficult for people to implement on their own.

Thoughts?

@shawnlauzon
Copy link

Yes, this is the same conclusion that we came up with. feathers-authentication-management would only implement it with those warnings, and since it's difficult to ensure the user understood the ramifications, better to simply include it on the documentation.

That being said, the fact that this issue exists along with your explanation gives enough information for clients to follow your instructions if they so desire :)

@claustres
Copy link
Collaborator

This issue being very old we close it as we are trying to give a fresh look, please reopen if required.

claustres pushed a commit that referenced this issue Oct 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants