Explicitly about the "forgot password" thingy.
This little issue that appears in every single project where users can register themselves that say...
For further actions, you may consider blocking this person and/or reporting abuse
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. 🤣
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 😅
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.
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)
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.
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:
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".
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.
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.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😅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.
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
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...
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
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?
Yep -- one of our competitors is open source -- hanko.io
Thank you for sharing, much appreciated! I'll take a look at both 😁
Excellent! If you have any questions about Passage, let me know!
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
Will do -- thanks for taking a look!
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 🤷🏻♂️
😂😂
source
This is now my favorite solution! :D
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.
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.
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.
Totally agree but that's just what most clients don't want 😅