I’ve never understood this request because this already works:
press “forgot password” button on login page
press “submit” button
get email
log in
I guess the only difference is that you’re not changing the password, but if you really don’t care what your password is and want to log in via email all the time, you can just smush your hands on the keyboard when entering your “new” password every time.
Yeah it’s pretty much mostly a language change, rather than functionality change. Instead of saying ‘you should go through this probationary process because you made a mistake ’, you instead say ‘Hey, do you want a magical link that logs you in pretty much instantly?’, but the process is the same.
I’m on a new computer. One of the few passwords I can remember is that of my email, which is also protected with 2FA. However, on any site that doesn’t support social logins, I’m using a password manager so I can use long, secure passwords. But I’m not always on a device/browser where I’m allowed to use my password manager.
In these cases, an “email login link” would be strongly preferable to a password reset, since the problem isn’t that I’ve forgotten my password; I never actually knew my password in the first place. If I change my password, that won’t match whatever my password manager has got stored.
Yep, it’s still on the table. However I think this task would probably have to be one of several pr-welcome tasks, since I doubt it’d take 3 months to figure this one out.
Yep, this is still available. But keep in mind that since this change has security implications, it’ll probably be a pretty slow-moving process as we need to review every code change very carefully. As already mentioned, it should be done in conjunction with a couple other tasks.
Also, this isn’t a good “warmup task”. Better look through #starter-task::tag for that. Save “Passwordless signin (+others)” for your SoC proposal.
May I ask some security experts here:
Is this procedure less or more secure than the default PW way?
Just as an side aspect, I’d like to mention:
What if an attacker catches the plain text mail and login (maybe automatically?) - in first place to get control over the account.
He would try to change the mail adress to make an account recovery - at least for the moment - impossible.
Now he/she has time to get everything she/he wants to know.
I would say for any corporate Discorse usage, it could become pretty dangerous.
So, I would suggest:
to disable some settings like changing the mail adress for at least x minutes.
offer some kind of 2FA in addition (optimal)
make sure, if someone from ouside the country (better: some location radius over x kilometers/miles, relatively to the last 1-3 locations, the admin and user itselfs will become immediately notified over the geo location, IP and time… (like Apple does)
… so there is a small chance to prevent / stop illegitimate access, in case there is something suspicious.
Why do we need TLS/SSL encrypted web sites and passowrds at all, if there is no intend to fix this? Why are you hashing the PW before sending it to the server, if the mechanism to bypass it, is so easy?
I really think, it shouldn’t be that easy to hijack user accounts in seconds. Even for bank account access via ATM, you need at least the data on the card and a pin. It a petty, that mail encryption is that kind of complicated for inexperienced users nowadays.
Make sure to use WebAuthn (the api that supports “More than just U2F”) when implementing, it will also support things like fingerprint sensors.
(and also android safetynet which is a big scam to punish people for rooting their devices)
I don’t believe Discourse does this.
There’s plenty of reasons why content integrity and authenticity are important, aside from the confidentiality of login, but I’m sure you already knew that.
Thank you @fantasticfears for lying the ground work here! I made some changes as to how error messages are displayed and made the rate limits more aggressive for the new routes.
As per @sam’s request, the feature is also off by default and can be enabled via enable_local_logins_via_email site setting.