I believe that Discourse is already throwing away many standardized conventions already in the name of evolution of communication and related technology. Moving to something where privacy, security reliability and simplicity is inherent like SQRL seems like the “perfect match”.
SQRL a Better Authentication Method.
I am suggesting adding an alternative method which could be merged into the login/registry screen.
The websites I’ll link for your own study and consideration are sqrl.pl and grc.com both have valid and powerful explanations of this technology. Basically for those of you who don’t like clicking foreign links without a short pitch. Heres the idea of how SQRL works.
The problem
When you first show up to a website you’re usually presented with a register/login page which requires that you punch in a bunch of personal information before you can register. The way that this usually works is that you have a Username or Email and a password. This is all find and dandy but we all know that it can be tough to host and effectively secure authentication credentials against attack and exploitation.
This relies on the fact that you manage the length and complexity of your passwords and usernames. Otherwise it relies on hopes and dreams to essentially stay under the radar from robots attempting to farm and exploit your accounts.
Some Duct Tape (TwoFactorAuth/MultiFactorAuth)
To combat insecurity issues with brute forcing and dictionary attacks we’ve come up with a new magical solution called Two Factor Authentication or Multi Factor Authentication where you use some randomly generated OTP (One Time Password) as well as your main password. This gets arduous and frustrating when you have 30 seconds to type in a password before it expires. Or you have to wait for an SMS to be sent to your mobile device reliably.
The Many Issues With MFA/TFA as a Bandage Solution
You now have the issue of always keeping track of not only your Username/Email and Password but you also have to hope that your phone is charged and that you remember the pin for your MFA/TFA so now you have to concern yourself with all of the following:
The location of your smartphone
Smartphone is charged
Integrity of your smartphones flash storage
Secure backups of your TFA/MFA
The user ID that was used [Pin/Email/Username/ETC]
With SQRL you are offered a QR code which you can scan or click (depending if you’re on a mobile browser or not). This QR code sends a bunch of gibberish to your mobile scanner app which you now use your private master key which is generated by the mobile app and then send the signed result back to the website/service to prove you are who you are and that you’re checking in.
The Issues With SQRL
Location of your smartphone
Integrity of your smartphones flash storage
Your ability to securely back up SQRL identities
Remembering your Passphrase for SQRL
This list is significantly shorter and a broader explanation and case for use is made more effectively on the websites linked in the opening paragraph.
Really just making suggestions I don’t code personally, I’m basically just making feature requests until Discourse is such an awesome project to me that I have no choice but to run it
The projects that I run are generally small open source stuff for gamers/game mod’ers. If it wouldn’t cost heaps of cash to get it coded I might pitch some cash at the idea. But I can’t really afford much for it right now. So they’d have to be willing to work for cheap.
True enough, although I also see a lot of alternative issues that arise from this model. This sounds like it requires you log into your email or your android or something. Which sounds like a lot of extra time involved.
SQRL is nearly instant and already a complete solution which accommodates for a lot of security considerations. Its basically similar to OAuth minus the third party.
I do suggest taking a glance at it I think you might be impressed with its overall design. It really eliminates a lot more than what I wrote. I was just hoping to highlight some of what really stood out to me.
I am curious what the usual cost for something like this is.
Fair enough thats way out of budget for what we would need it for.
SQRL just seems like a reasonably decent alternative option to UserID // Password // MFA options which seems to be very security and privacy conscious. It has huge benefit of being designed to be extremely difficult and complex to crack.
yes I suppose this is accurate its still slower and a lot of work, since theres a vast majority of people who probably don’t use inbox.google.com email tends to get buried or is slow or even worse completely blocked in some cases.
You do bring up a good argument essentially against MFA/TFA since you can generally reset your login credentials with your email regardless of the presence of your MFA/TFA. This in itself sounds like a security design flaw. In a perfect world people would have effective methods to handle passwords and such. The situation with SQRL is all you need to do is keep track of your phone and keep it backed up somewhere. Your password and email don’t play into the equation at all those become essentially optional. Granted you do basically rely on the person who owns the mobile phone to keep the thing backed up properly.
Further, there is now an SQRL forum for help with use, integration, et cetera. This may be worth looking into as a core integration, as it addresses a number of the security and privacy issues related to usernames and passwords.
Is this thread necromancy? Yes. But, more importantly, is it warranted thread necromancy? Also yes.
I worry this is too late, given U2F is a standard in browsers these days, apple are pushing for apple auth on mobile, we already support login via email
So I really wanted to make a SQRL plugin for discourse however my skills in the discourse dev platform are suuper new and I don’t have a ton of time to learn a new framework , language etc.
So I opted for the next thing which would work, an OAuth 2.0 provider for SQRL this is done and working and it is now live in “Alpha” release at
