JWT Password Reset Codes

[ch4ot1c]

(Improvement Suggestion) https://github.com/dwyl/learn-json-web-tokens In the FAQ, this guy outlines a strategy for using JWT as the security code. My focus (for my use-case) is particularly on password reset. This strategy has a lot of security advantages, being both a longer string with timeout semantics within, and extensively maintained as a library. A 8-digit hex value is fairly secure, but certainly a heavy brute-force attack on a web server that never throttles the attacker might just be able to compromise the current system.

Altogether loving the deitch/activator and your thorough documentation ~ Thanks again!

[ch4ot1c]

As a note, I am more than happy to contribute to implementing & submitting a PR for this, but it would be somewhere in the 'a few months' range due to current work

[deitch]

I like that. I have used JWT extensively in docker registry (built a Ruby gem for direct access via the REST API, as opposed to having to go through a running docker engine), and I do something similar for cryptographically authenticated access token in https://github.com/deitch/cansecurity

I am trying to think how to expand activator. What would make it useful beyond what it does? I had one person approach me about an all-in-one (providing the mall service, too), but not sure if that has appeal?

[ch4ot1c]

I like the nodemailer + simplified DB wrapper component a lot. I think 'nodemailer' is fine as a dependency and doesn't need to be more tightly coupled.

When thinking about things I don't need activator for, I think about Twilio and similar 2FA strategies. They provide primarily SMS solutions to these problems, though - certainly not NodeJS email-based strategies. Seems like a good place in cyberspace for activator =]

[deitch]

I am a bit confused. You still need activation and possibly password reset for 2FA, because one of the factors is something you know, which you may need to reset. Similarly, we are trying to confirm that the contact information (email) is valid.

Seems like a good place in cyberspace for activator =]

Mind clarifying? Sorry, slow-mind-Friday... :-(

[ch4ot1c]

https://www.twilio.com/docs/tutorials/walkthrough/two-factor-authentication/node/express#8 This article, as well as the slides before and after, has some nice diagrams and examples of how their 2FA system works ('Authy' is the name of this Twilio sub-component). A quick google search for 'Twilio Password Reset' brought me to this link ( https://www.twilio.com/use-cases/two-factor-authentication ), which has the statement: Easy password reset Send password reset requests within the app's 2FA workflow. Reduce the time it takes locked-out users to regain access.

Unfortunately, in all their guides, I haven't found an example for this case specifically. Seems like their way to do it would be with a 1-time SMS passcode or their OneTouch service, and then manually sending a followup reset email. Haven't seen anything in their code that sends emails at all though, so thats where I envision activator bridging the gap

As a side reference, here is their walkthrough for account verification thru express/mongoose: https://www.twilio.com/docs/tutorials/walkthrough/account-verification/node/express

I'm still exploring + learning these possibilities myself, so forgive me if I'm mistaken in any part

[deitch]

Yeah, I know Authy as well (been doing some form or another of multi-factor auth for too long....).

These all boil down to, "what's my reliable side-channel to the customer?" The main channel is the Web interface. Sometimes we cannot trust that:

1. When the user first signs up and says, "this is my email"; prove it!
2. When the user asks for a password ("something you know") reset and says, "really, this is me"; prove it!

For the first case, we verify by actually using the email. If you can interact via that address, then by definition it is valid for you to use. This is the activation part of activator, and if you use a phone number instead of an email, then it is the SMS part of Authy.

For the second case, we need to prove it is really you. If you have a pre-confirmed 2FA set up, that might be sufficient for using that channel for a password reset. Then again, it might not; I could argue the security implications of both sides.

In other words, authenticator is for not-infrequent-but-non-regular use cases.

Most of Authy (and other 2FA) is around regular-and-frequent use cases. On every login, prove it is you. E.g. use password + second factor (HOTP/TOTP), or on every transfer, get a confirmation.

I am impressed with how Twilio started as voice services, realized a common use case and built entire services around them in Authy. Hats off.

All in all, while I see activator filling its niche (as you said), I still don't quite know how to expand that. It is part of the broader "identity proof" functionality, but there is something different here in potential....

[ch4ot1c]

Very well summarized. I'll keep it all in mind and get back to you if/when I come up with a relevant addition to the lib. Thanks a bunch for the discussion

[deitch]

Thank you! It is very helpful to hone the understanding and usages.

JWT is in the cards, though, as soon as I can get to it. I will put it here and in cansecurity. I particularly like it here because I don't need to have a field in the database. Doesn't get better than that.

[ch4ot1c]

Great! No rush, I'll keep my eyes open for a branch

[deitch]

Phew. Tests are all done, as is documentation. Now for the implementation (which usually is easier anyways).

[deitch]

And activation works. Just password reset now.

[deitch]

A few tests left. This is pretty cool.

[deitch]

BTW, I made it a breaking change. New major version, and completely dumping the database write. The API is far cleaner now, and requires less support.

[ch4ot1c]

Excited to review and implement it =] Thanks again

[deitch]

Version 2.0.0. Pushed to github and published to npm. Cool!