People's reactions to SQRL

  • New Wordpress Plug-In Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to the Wordpress plug-in which Daniel Persson originated and has been making great progress on. You'll find it under "Server-Side Solutions."

    /Steve.

shanedk

Well-known member
May 20, 2018
317
86
I thought I'd make a thread where we can report the reactions we've gotten from showing people SQRL.

Last week, I showed it on a livestream to my YouTube audience and, despite the fact that (with one exception) they weren't a techie audience, the response was overwhelmingly positive! We digressed a lot, so I edited a shorter video with just the SQRL discussion:


I'm not exactly a big channel, but the more people we show it to and get their reactions, the better it will be.

I know some others have done something similar, but I don't know the links, but please post anything like that! The more feedback we get, the better.
 
  • Like
Reactions: Vela Nanashi

ramriot

Well-known member
May 24, 2018
73
9
Great blog post, a couple of clarifications:-

Under "Major Concern: No Deauthorization Mechanism", as well as the Re-keying process which requires the elevated rights obtained by knowledge of the Rescue-Code there is a Lock process that can be done with normal rights. Yes, this has to be done on a site by site basis though at least one client writer intends to add a protected database of associated sites that would allow this to be automated.

Under "Phishing is sorta trivial", offering a phishing site under a different domain name & then using that trust to socially engineer further information from you has nothing to do this SQRL & there is no conceivable way it could be addressed. The one advantage SQRL has over this being done with OAUTH etc, is that the identity proof given to the site is useless for anything except proving identity to that one phishing site.

You mention in passing same IP protection put this is a defence for a completely different attack scenario, see CPS & Same IP Protection in the docs.

Under "Malicious Clients" this is exactly the same issue as with Password Managers, I believe there is even a Security Now Episode that features an independant review of same exposing copious bad issues

You should also think about removing the link to https://security.stackexchange.com/questions/43374/could-sqrl-really-be-as-secure-as-they-say, that posting is based completely around a much earlier version of the protocol & much of that has now been replaced, plus the poster misunderstood several of the key aspects of what was there at the time. Unfortunately because the internet has a LONG memory we need to be careful pointing to bad information & this promoting its rank on search.
 
  • Like
Reactions: Dave

ohryan

Member
Oct 8, 2019
8
1
Hey, thanks for actually reading my post!

Yes, this has to be done on a site by site basis though at least one client writer intends to add a protected database of associated sites that would allow this to be automated
I meant to mention this but got kind of distracted. That's the beauty of this system, a client developer could add improvements such as this without the need to affect the underlying protocol.

Under "Phishing is sorta trivial"...
I think calling this "sort of trivial" was a mistake. The amount of effort needed to pull off the sort of phish I was envisioning is high. Much higher than a simple username/password field capture.

What I was trying to get at was that the very "simple" and "quick" nature of SQRL could make it harder for a user to notice phishing. A user using this system regularly could be lulled into complacency. "Yup, looks like a QR, I'm good to go." Because the protocol is so seemless, there is less even less time for a user to second-guess their actions.

there is no conceivable way it could be addressed
I disagree. As a simple solution I would think that clients could highlight the site ownership attached to the SSL cert (much like chrome and firefox do today). This wouldn't "fix" the problem but it would at least give users a fighting chance.

Under "Malicious Clients" this is exactly the same issue as with Password Managers
You're totally right. Malicious password managers don't seem to be a scourge on the internet. So it's unlikely that this is a real concern.

You mention in passing same IP protection put this is a defence for a completely different attack scenario, see CPS & Same IP Protection in the docs.
It sounds like I misunderstood what this was about, I'll take a look at the docs.

You should also think about removing the link to https://security.stackexchange.com/questions/43374/could-sqrl-really-be-as-secure-as-they-say, that posting is based completely around a much earlier version of the protocol & much of that has now been replaced...
I'll take it in to consideration. Most of the potential problems with the system have little to do with the protocol, they're logic problems. It was informative to read other security minded individuals discuss SQRL from the starting point of "this is broken." I feel like it's a good counterpoint to my otherwise extremely positive post.

FWIW I'm planning on writing a followup post with some more thoughts and I'll be sure to include the points discussed in this thread.

Thanks again for the feedback. I've been blogging for a long time and it's a rare occasion when I a post spawns some interesting conversation. I am really excited about SQRL!