Yes - that’s passwordless / magic link.
Note that “scan a QR code” by itself does nothing. That QR code represents a secret string that then has to be sent somewhere to log in.
Which is conceptually identical to “click this email link to log in” because that link has a secret string in it.
4 Likes
The difference with what is implemented now as email log in, is that you would log in to another device, not the device where you click the link. Hence my suggestion that this could be implemented as a notification inside discourse:
- You are already logged in in your phone;
- you want to log in into a desktop browser;
- you enter your e-mail in the desktop browser;
- you receive a notification in discourse that you tap in your phone;
- your are logged in into your desktop browser.
2 Likes
I personally prefer any API support for FaceID and TouchID. Apple and other smartphone manufacturers should integrate certain features for WebKit 
Maybe the discourse iOS and Android app could work as bridge element for easy authentication?
3 Likes
I will NOT use biometrics, not for phone, not for web.
Maybe as a 2FA, but not as a login/unlock method.
Just because the capture isn’t exact, biometrics are always a secondary form of authentication. Even if you don’t know the associated passphrase the biometric input has to be matched against a recorded entry and a token/key/password sent across to the target system.
You can already use FaceID or TouchID today for authentication by using a password manager such as 1password. That has to be the strategy too, nobody wants their biometric data to leave their device, this is precisely why Apple has their “secure enclave”. In iOS12 password managers can already expose their data directly to safari, no need to open another app each time you want to sign in.
The notification step isn’t really necessary if you’re on a device with a camera, or are willing to enter a displayed passphrase onto your mobile device. By entering your username (something you are) and then scanning a code or entering the displayed code onto your device (something you have) you close the loop. Notifications are a good integration for 2FA, but beyond that there are all kinds of places where they can break down.
It doesn’t really answer the question as to why this is necessary though. Whatsapp can be used without an email address, so can’t send a sign-in link via email - that’s the problem they needed to solve. You could equally solve this problem by sending an email to the mobile device with a clickable link which confirms the session on the desktop PC.
Totally agree in security perspective.
But for most people, it could be a improvement of their current security situation. Most people use 4-digit passcodes on their phones and sign up in hundreds of web sites by using the same credentials.
My bank (Deutsche Bank) even allows me to login with Face/TouchID AFTER a initial setup with full credentials.
Sure, there should be some security rules that probably recognize not legitimate access attempts. But if e.g. the devices are in the same (trusted!) local network and share some fingerprints / secret keys, I would allow my smartphone to grant the access.
We should keep in mind, that most discourse forums are not implemented in high security environments. Most people just wanna have a great and easy to use community experience without to care about fancy passwords and so on…
@1password:
I don’t trust them. They don’t provide their code base as open source. But I would trust the discourse app much more, if the source files are publicly available.
this is precisely what I want.
This is the key point.
Also for a monolithic “everyone on the same platform” service like say Instagram, you could have the Instagram app scan a QR code and send that secret string encoded in the QR code to the hard-coded instagram login HTTPS API call… which is impossible to cheat or phish.
The reason this strategy won’t work for Discourse is because there is no one monolithic platform or app. There can be millions of different Discourse instances with their own domains, running on their own servers.
6 Likes
The other dimension for me is that any app dependency almost makes Discourse a mobile-first ecosystem.
Today it’s as viable in a call center or corporate environment as it is a bicycle club. You can use the web, mobile, or in some cases only use email and never touch a web interface directly. It’s that versatility which will allow future open platforms to thrive.
None of us want or need another walled garden.
2 Likes
there are web APIs for camera, and the camera used should be the logged out one.
Now you’re talking about using another vector which could be spoofed as the process would need to identify the specific camera used in order to make sure it was the logged out one - and not every device / OS allows for that level of identification.
I just mean the camera would be the login method. “scan login”. on the logged out device.
you’d go in settings (on logged in device) to generate the qr code.