Passwordless signin via email link

Continuing the discussion from Is there a way to make the password requirements more simple?:

Prior art:


Update: Spec here:

3 Likes

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.

1 Like

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 :cop:’, you instead say ‘Hey, do you want a magical :unicorn: link that logs you in pretty much instantly?’, but the process is the same.

7 Likes

That’s not the actual “forgot password” flow though. It goes:

  1. press “forgot password” button on login page
  2. press “submit” button
  3. get email
  4. create new password
  5. log in

The feature here is essentially about removing the (4) create new password step.


Here’s a scenario I quite often find myself in:

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.

16 Likes

Hi,
Is this project idea still available for GSoC? I am interested to take this up!

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.

1 Like

@erlend_sh
Sir, Is this topic still available and can I start working on it?

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.

5 Likes

Sir,
I am starting with some starter tasks and will have my GSoC application/proposal on this topic.
Thank You for your guidance.

3 Likes

Eh, I feel the rush to implement this feature. Up for grabs?

6 Likes

heh, sure go for it!

2 Likes

I added this to 2.0 and am assigning this to @tgxworld to look at. We have a PR for this by @fantasticfears that just needs a bit of refining

3 Likes

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:

  1. What if an attacker catches the plain text mail and login (maybe automatically?) - in first place to get control over the account.
  2. He would try to change the mail adress to make an account recovery - at least for the moment - impossible.
  3. 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.

I think as a minimum when we pull in this feature it would be default off.

In a 2fa scenario you would need magic link + 2fa which I think gives plenty of security and allows you to forget a password.

5 Likes

This is the same threat level & attack vector as intercepting your password reset link, which is already a default feature.

7 Likes

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.

Hmm :thinking: makes no sense for me

Which is why what you really want is 2fa, which is coming next year

8 Likes

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.

2 Likes

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.

https://github.com/discourse/discourse/commit/03b3e57a44da228bca7296bd752e26447956e1d6

10 Likes

Maybe this feature could be integrated in a more visible place as it’s very useful:

I suggest if there could be a button here saying Login with email
Something like this one:

2 Likes