DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Can we talk about this feature? Please
JoelBonetR
JoelBonetR

Posted on

Can we talk about this feature? Please

Explicitly about the "forgot password" thingy.

This little issue that appears in every single project where users can register themselves that says "Implement the forgot password feature" πŸ˜…

It's so common than most of the time people even doesn't split the issue. But should we?

Well, let's check the nuances on that.

workaround

  1. Show a message with a "forgot password?" link/button whenever the user fails to log in.
  2. Ask the server to send the "forgot password email".
  3. Catch the request on the server.
  4. Generate a token on the fly
  5. Generate a Link that includes this token
  6. Inject this link into an email template
  7. Send the email with the template
  8. When the link is clicked, we need to validate the token
  9. If it's expired, redirect to the login, showing the "forgot password?" link/button again along with a message that says "The link is expired, please try again".
  10. If it's OK, redirect the user to a view.
  11. This view has -usually- two fields. New password and Repeat password.
  12. Check that each individual password field is aligned with the required pattern (min. 8 chars, 1 uppercase, 1 lowercase, 1 special char...) and that both are equal.
  13. On submit, check the token again. Why? well, it can expire in the meantime, if this happen, return to point 9.
  14. If the token is OK, update the password for this user.
  15. Redirect to the login view with a message that says "your password has been updated successfully"

Munching the workaround

We can send another email once the password has been changed, that typical "Your password has been changed, if it wasn't you please, call the police, the SWAT, the marines and send us a ticket, your entire family may surrender to hackers".

Yet another thing is to handle 2FA if it's implemented in your app. You may want your users to have the chance to use it to make this process easier -for them- but as the 2FA is not something mandatory, you still need to do the rest while providing this other workaround😁


Answering the question I think we all can agree on that being a big YES, splitting the "forgot password" issue is a must (Just in case I mean Github, Gitlab, Jira... any issue tracker).

We need definition for email templates and nuances on some of those points and splitting all this overheat into smaller chunks also reduces the procrastination.

The Problem

This entire thingy is something that I usually procrastinate or delegate. The reason why is because IT IS BORING to develop (at least to me).

It is so boring that I coded a calculator and an NPM package just to avoid coding that forgot password thingy the last time I had to.

And I had to code it again this week. Glad this time I split myself that bunch into several smaller issues, otherwise this post would probably be like "Mom, look what I've done" talking about whatever crazy BS I could have come up with.


I'm still wondering why in the seven seas frameworks don't implement -yet- a nice friendly way to deal with that. I mean like... call this function with a config object as param and WOOSH points 5 to 10 automated!

I'm even thinking on create a npm lib if nothing exists just to spend like 80h trying to automate something worth a morning and making it as dynamic as possible to fit as much projects as possible.


Do you know any tool to help hundreds? If nothing exists, would you like to collaborate to bring something new?

Top comments (26)

Collapse
syeo66 profile image
Red Ochsenbein (he/him)

Well, well, how many time I read some "specs" (if I dare to call it that) just stating "the user wants to log in", "the user wants to create a new account" and of course "The user wants to recover his account after forgetting his password". Everybody seems to assume this is straight forward. And then the developer implements his vision of the feature and - of course - someone had something else in mind...

There are - as you said - so many things to think about on each of those steps. Yes, sure it is usually the same... but then also, different. I'm not sure if a tool/library is fixing that because usually the problem are the missing specs, not implementing it.

On the other hand, implementing the same thing over and over again isn't good either and having a library at hand would be great.

Oh, and while we are at it, can we please start teaching people to NOT use password restrictions (maybe requiring a minimum amount of characters, yes, but that's it... I don't understand why 'sloped-pushing-nag-unbent' shouldn't be my password. It's probably better than 'P@ssw0rd'). But then we should ditch passwords completely... but that's another story. 🀣

Collapse
joelbonetr profile image
JoelBonetR Author

Hahaha agree on that password restriction thingy. There's one thing that screws me up and that's those sites that "advocate" for a good security and then you can't use spaces between your password. I fail understanding why "I fail understanding why" can't be my password πŸ˜‚ But yes, that's a completely different topic.

And yes as well to the lib thingy, it would be nice but I'm sure as soon as I put my brain to work and define it, multiple issues or TBD s will appear πŸ˜…

Collapse
fjones profile image
FJones

So, spaces are a funny thing. Because of URL-encoding, we historically don't think of spaces or + for acceptable characters, even though "password in URL" has been a no-no forever.

Thread Thread
syeo66 profile image
Red Ochsenbein (he/him)

Yeah, but this should be a problem of the past (and at least solvable). I mean maybe we shouldn't even send any password across the network and hash it already before sending it (and store a hash of the hash in the database)

Thread Thread
fjones profile image
FJones

Oh, absolutely. Just explaining how one of these "unspoken rules" came about despite being completely nonsensical. For a similar reason, % is often not included in the allowed character set, even though there's no real reason for it.

Thread Thread
joelbonetr profile image
JoelBonetR Author • Edited on

It's more a blind design decision, those which are made just by copying what others did than thinking in your product.

There's no technical reason for avoiding spaces other than being necessary for executing some hacks, i.e. SQL injection like setting this as value for your password:

myPassw0rd') OR 1 = 1
Enter fullscreen mode Exit fullscreen mode

I'm sure there are multiple sites in where this still works πŸ˜…

Disclaimer: This example is for login forms not for registration ones, either way if you are going to hash a password it will be capable of getting spaces within and no issue will show up I guess that "old ways are never lost".

Thread Thread
joelbonetr profile image
JoelBonetR Author

well, space is a valid character, it just gets encoded to %20 and the server gets it and decodes the %20 to a space again. It has never been an issue.

Moreover you can set spaces in other fields like in the name one πŸ˜… so I guess an arbitrary reason should be behind that.

I'm honestly curious to see if someone appears and states some weird technical reason for not admitting spaces inside a password that I don't know about.

Thread Thread
fjones profile image
FJones

While true, space can also be encoded as + (and in the case of mailto links, must be). And generally, historically, usernames and passwords alike have been restricted to the same character set: [A-Z0-9?!.*_-], for purely historical reasons that these are non-conflicting characters likely to be used.

Thread Thread
joelbonetr profile image
JoelBonetR Author • Edited on

Yup but what's shocking is that you can set "Keanu Reevs" which contains a space in a "full name" input, and it's OK.
But then you want to try a space in the password and most sites say "Bad Bad!!" and it's like... a single space in SHA256 will look like that anyway:
36a9e7f1c95b82ffb99743e0c5c4ce95d83c9a430aac59f84ef3cbfab6145068 πŸ˜…

Thread Thread
fjones profile image
FJones

Like I said, it makes no sense, and for some reason the more afflicted field (username) got less restricted much much earlier than passwords. It just grew to this point historically, through some very incoherent steps.

Thread Thread
fjones profile image
FJones

Also, mild funny streak: You are expecting people to use SHA-256, that's already a step up for a lot of sites using SHA-1 or MD5 still. :P

Thread Thread
joelbonetr profile image
JoelBonetR Author

hahahaha And a young junior myself encoding passwords in whirlpool back those days πŸ˜‚πŸ˜‚ can't even remember, was it 512 bit worth of hash maybe?

Badass past-me...

Collapse
passagenick profile image
PassageNick

Or you could just easily and quickly implement a totally passwordless solution that's easier on your end users.

Just sayin'.

Nick Hodges
Developer Advocate
passage.id

Collapse
joelbonetr profile image
JoelBonetR Author • Edited on

Hey!
That's a good idea but at the end I need to develop what client's want πŸ˜…

Moreover I don't know any passwordless solution that's open source and free to use (onPremise of course) to use in my sideprojects, do you know any?

Collapse
passagenick profile image
PassageNick

Yep -- one of our competitors is open source -- hanko.io

Thread Thread
joelbonetr profile image
JoelBonetR Author

Thank you for sharing, much appreciated! I'll take a look at both 😁

Thread Thread
passagenick profile image
PassageNick

Excellent! If you have any questions about Passage, let me know!

Thread Thread
joelbonetr profile image
JoelBonetR Author

Perfect! I'm now building something public on my own which won't require (for now at least) authentication but I'm adding this to the loop just after that.

Also please, ping me if you write a post to showcase 😁
It could serve both for me learning more and to send it to the senior architecture team (I like to call them the council of wise) just in case it's suitable for any incoming or existing project πŸ˜‰

Best regards

Thread Thread
passagenick profile image
PassageNick

Will do -- thanks for taking a look!

Collapse
nevodavid profile image
Nevo David

Honestly in my startup (Linvo) I didn't build this feature, only when I scaled a little.
But looking back I should def be using Auth0 or some alternative, why bother πŸ€·πŸ»β€β™‚οΈ

Collapse
joelbonetr profile image
JoelBonetR Author

πŸ˜‚πŸ˜‚

source

Collapse
ravavyr profile image
Ravavyr

This is now my favorite solution! :D

Collapse
theaccordance profile image
Joe Mainwaring

If there’s one thing I’ve learned building and maintaining Auth features for the better part of a decade, it’s that I hate sinking tons of time into features that only support the primary value-add of your product. I would much rather at this point outsource Auth to a third party like Auth0 or Okta and factor the costs into my pricing model.

Even for personal projects, I’m using third-party Auth. This is partly because I already learned how to implement it, but in truth it didn’t take a lot to figure out. Probably equal to the happy path for writing my own - except I get the full package: user management, reset workflows, 2FA, etc.

Collapse
joelbonetr profile image
JoelBonetR Author

Well in this specific case (password recovery) you need to code almost everything anyway isn't it? πŸ˜…

You get an API which provides some ease of use in comparison but the workaround is up to you.

Collapse
theaccordance profile image
Joe Mainwaring

Depends on your chosen vendor! I’ve used Okta in the past for small projects and the entire feature (views, workflows, APIs) is owned by the vendor. They simply return to my app after authenticating.

Thread Thread
joelbonetr profile image
JoelBonetR Author • Edited on

Totally agree but that's just what most clients don't want πŸ˜…

🌚 Life is too short to browse without dark mode