
SQRL – Secure Quick Reliable Login - sr2
https://www.grc.com/sqrl/sqrl.htm
======
cm2187
I am unfortunately not bullish that this will pick up but there are strong
arguments for this way to authenticate.

\- you would typically store the private key on a disk-encrypted app-
whitelisted iphone, so that the computer you are browsing with, whether yours
or a public machine, is never involved in the authentication. Effectively this
achieves 2FA. And you don't care if the machine you browse with is
compromised.

\- this does not rely on a third party, it is purely an authentication
mechanism. So it removes the risk of that third party tracking you, selling or
leaking your data.

\- it should be fairly practical and easy to use, does not rely on installing
anything on the machine you browse with

\- the website you authenticate to can be hacked, it stores no useful
information that can be used by another domain

I am not sure Gibson has the audience in the sillicon valley required for this
to become mainstream. But the principle makes a lot of sense to me. Of course
your are still exposed to the password protecting your private key being
stolen, which gives the attacker access to everything, but this is no
different from a password manager. Except that unlike a password manager, you
do not need to enter that master password on the machine you are browsing
with, which considerably reduces the risk.

~~~
cormacrelf
There's a slight problem. It doesn't 'effectively' achieve 2FA at all. If I
lose my phone and lose my master key, I lose my all my identities, and even if
I somehow remember them, I can't prove they are mine.

    
    
        HMAC(Master key + Domain)             -> private key + identity (public key)
        HMAC(Master key + Domain) + challenge -> response
    

Lose that master key, and you can't get anywhere. By contrast, FIDO U2F works
loosely like this:

    
    
        1. first factor
        2. HMAC(Master key + Domain) + challenge -> response
    

Key point being that it's still 2FA, where SQRL is still just one factor. If
you lose your FIDO device, at least as it stands, most sites make you have a
token generator app as well, or at least a path through customer support.

It may help to think of an email + password as being two factors, and various
2FA solutions actually being _three_ factors. Email is something you can prove
independently of your password. SQRL has exactly one factor, and zero failover
strategy.

It's debatable whether it should be possible to get through customer support
after losing anything, but the 99% of online security infrastructure that
builds a chain of trust upon your email address really does work for most
people in most cases. It's terrible that email addresses are easily correlated
across different websites, but the reality is that any replacement identity
solution needs to be as easily restored in case of failure.

For SQRL to work and give you an out for lost master keys, it would need at
least a way of creating a redundancy, like replacing HMAC(Master key + Domain)
with an asymmetric negotiation of the correct identity, or adding another
layer of indirection that makes the master key replaceable.

~~~
cm2187
Depends on how you define two factor. To me it is using a different device
than the device you authenticate with and unless you compromise that device
you cannot authenticate any other way.

The way it deals with compromised private keys is that you can store the list
of websites you authenticated to on a central location and run a reset of all
your authentications on all websites in one go from there. But then it relies
on a third party.

I don't pretend that this is the ultimate solution (nor am I aware that there
is an ultimate solution) but it does seem more secure _and_ practical than
anything else I have seen so far. I am sure you can make more secure but less
practical and of course less secure and more practical.

~~~
HurrdurrHodor
2FA requires 2 authentication factors like a password & a token i.e. your PIN
and banking card. It doesn't really have anything to do with where you enter
those. [https://en.wikipedia.org/wiki/Multi-
factor_authentication](https://en.wikipedia.org/wiki/Multi-
factor_authentication)

------
md_
SQRL has always annoyed me because of Gibson's propensity for presenting this
as novel work. QR-based logins have been around for a long time--as with
[http://www.zdnet.com/article/open-sesame-googles-no-
password...](http://www.zdnet.com/article/open-sesame-googles-no-password-log-
in/).

Of course I don't know what the mechanics of Sesame were, and Gibson does a
good job of fleshing out a particular protocol, but this kind of hype seems
typical of Gibson.

That said, he also overstates the value of SQRL quite a bit, I think. It's
certainly a good system for preventing use of passwords--which is valuable in
its own right--but his handwaviness around implementation hides some obvious
flaws.

First, if this is a mobile app--which seems most likely--then we can't
actually assume IP sharedness between the app and the login browser, so this
is really trivially phishable.

Second, if this is client software on the same machine as the browser, why do
the silly QR scan thing when you could just have some solid browser
integration that actually validates the server SSL cert--and is thus phishing
proof--a la FIDO? Hell, even a browser-based password manager is safer against
phishing than this, since those at least can validate the domain.

It's hard to see in which context QR scanning is preferable to the
alternatives already in existence--FIDO, which provides true security, or
phone-based "yes/no" assents, which are more usable and equally phishable.

------
nickik
I think this is great, but its time has come and mostly passed in my opinion.
The future belongs to FIDO UAF and U2F.

They are building a hole ecosystem with all kinds of capability and additional
security that SQRL simply can not provide. Most important being anti-phishing
protection. They are working on mechanism that would allow you to use the
phone as a authenticator even when working on your desktop, this is part of
the upcoming version of the standard.

They are already very popular and in a lot of hardware, they are working with
w3c to standardize, part of the Web Authentication group.

Some people wrongly assume that UAF is only about but it could also be
somebody entering a password or pin. The main attraction is that it allows for
independent evolution of authenticaters without the server having to know or
care (he can care if he likes). This will be a game changer.

~~~
floatboth
Uh excuse me?? SQRL provides excellent anti-phishing protection. There are no
reusable credentials across domains, and the domain can be displayed on your
authenticator.

[https://www.grc.com/sqrl/phishing.htm](https://www.grc.com/sqrl/phishing.htm)

~~~
hdhzy
Domain displayed is no real protection, actually its weakness is what drives
phishing. But the link you provided contains some interesting info:

> How SQRL changes things

> When using SQRL, users do not identify and authenticate themselves with a
> username and password. Instead, their unique user identity is derived from
> their secret master key and the website's full domain name.

So that's similar to what U2F does - domain name (origin) is part of the
protocol.

------
nkkollaw
This is awesome.

I just hope that people secure their phones. I recently got a new Android
phone and it has no password and no encryption by default, so I assume most
people leave it like that.

If you get access to my phone you can access 10+ years of pictures, email,
bank account, and all the services I use.

Besides this, I love it. Can it be implemented in a website, already, or is it
just an idea..?

~~~
jelv
It's not released at this moment. But it will be released soon™. Also there
are already a few examples in the wild (WordPress plugin, Android lib, etc)
here:
[https://www.grc.com/sqrl/implementations.htm](https://www.grc.com/sqrl/implementations.htm)

~~~
nkkollaw
But... I read in the comments that it's from 2013..? It will never be released
I guess, then.

[https://securelogin.pw](https://securelogin.pw) as another user suggested
might be a better alternative, then.

Too bad, I really liked the name.

~~~
Cyphase
It has been in development since 2013, but it still is under active
development, and is probably(?) going to be released relatively(?) soon.

------
eugene_pirogov
This is actually implemented in the biggest bank of Ukraine, PrivatBank.

1\. Open login page [https://www.privat24.ua](https://www.privat24.ua) on the
computer, you'll see a QR code,

2\. Take your phone, open bank's official Privat24 app,

3\. Within the app select "Scan QR code",

4\. Upon scanning, the page on the computer is reloaded and you are presented
with the dashboard.

Very convenient. I wish more services across the internet would provide the
same means to log in (although, of course not every one service can afford
having a dedicated mobile app).

~~~
wink
Sounds awesome, whereas my German bank still doesn't allow proper passwords,
only "PINs" no longer than 5 characters.

Fun fact, you can change your login though, it can be 15 characters including
non-alphanumeric. /s

~~~
elcapitan
Which German bank is that?

~~~
wink
Stadtsparkasse München - and I'm not sure if the other Sparkassen are better.
Maybe some are, you never know what exactly they share and what's different.

------
rs232
My bank has been using this for a few years now, and it quickly became my
preferred method of logging in. Open the bank app, scan the code, punch in a
PIN on the phone and the browser bank opens almost like magic. Very easy to
set up for non techies as well.

[https://secure.skandiabanken.no/Authentication/QRCode](https://secure.skandiabanken.no/Authentication/QRCode)

~~~
kennydude
Sounds a lot better than UK banks with their stupid "enter the third, fifth
and seventh characters of your password" which is frustrating

~~~
mbreese
It also makes you wonder how they know what the third, fifth, or seventh
characters of your password are...

I suppose they could create multiple hashes each time you change your
password, but I'm not optimistic.

~~~
arethuza
My UK bank requires a password and a separate secret phrase that they do the
letter selection from. You need to supply the password and 3 letters from your
secret phrase.

As my phrase is quite long I pretty much always end up writing it down or
using an editor.... :-)

~~~
kennydude
I have a lookup table in 1password as my brain can't work with indexing random
strings with numbers in them easily

------
ramriot
Very much comment here on this subject, unfortunately very much of it
references out of date or incorrect sources or even misses the point entirely
possibly due to the posters not understanding the underlying concepts.

I partly blame myself for the first part as I am a contributor to SQRL and
have been lax in keeping my part of the documentation current as things
progress, Steve has had similar problems.

As to the second, SQRL is not a 2FA succinctly it is a:-

Single factor (1FA), 2-party, Zero knowledge, pseudonymous proof of identity.

The use of QR-Codes was an early feature but is mostly relegated in favour of
same device authentication, with I hope a brand new feature (Client Provided
Session) that will effectively detect & then eject a MITM attempting a session
hijack from the connection.

The nature of the 2-party relationship is such that no site can determine
without the collusion of the user themselves if that user has an SQRL
authenticated account on any other site, hence pseudonymous.

Reference implementations require that the Master Identity file is stored in
an encrypted form and only decrypted at point of use by a key derived from
something only the valid user can provide (passphrase, biometric), thus user
to identity is confirmed.

Loss of an unprotected Master Identity File exposing the Master Key is not
fatal because although the master key will provide the means of access it does
not allow an attacker to update site specific keys. There is effectively a
Super-Master Key that is never exposed but protected with an exported system
generated encryption key that is held offline for such an eventuality.

Finally because this is a protocol cooked up by a group of enthusiasts we
always welcome constructive input and entities willing to offer support in
getting SQRL more widely understood.

------
s_tec
Aside from a few cryptographic details (like which elliptic curve to use),
this system is identical to
[BitId]([https://github.com/bitid/bitid](https://github.com/bitid/bitid)).
BitID is already being deployed in the Bitcoin ecosystem. For instance, you
can see it on the buy/sell service
[Glidera]([https://www.glidera.io/loginbitidqr](https://www.glidera.io/loginbitidqr)).

One benefit of doing this in the context of Bitcoin is that users already have
mobile apps that can manage private keys (with backups) and scan QR codes.
With Bitcoin, if you lose your keys, you lose money, so there is a tremendous
incentive for both users and wallet authors to get this stuff right. Using the
same technology for logging in an easy next step.

------
Veratyr
Something that I haven't seen mentioned yet is that systems similar to this
are already pervasive on the Chinese internet.

Here's Taobao's login page:
[https://world.taobao.com/markets/all/login](https://world.taobao.com/markets/all/login)

And Alipay's: [https://login.aliexpress.com/](https://login.aliexpress.com/)

Both have that little QR code icon peeking from the corner. You just click
that, open the relevant app on your phone and you're in.

~~~
md_
Flipboard also uses QRs. But to be accurate, this is a convenience feature,
not a security feature. It's still phishable.

------
Gehinnn
This is truly awesome! But I miss a single source that has everything users
and developers need to know. For SQRL to become mainstraim this is absolutely
necessary. Right now there is
[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm) (1),
[https://sqrl.pl/](https://sqrl.pl/) (2) and [https://github.com/vRallev/SQRL-
Protocol](https://github.com/vRallev/SQRL-Protocol) (3) and some other sites.
(1) looks a bit out-of-date in terms of design and has no clear instructions
how to integrate it into own websites. (2) links to (1) (3) could be more.

I am looking for a webpage like this: [http://swagger.io/](http://swagger.io/)
And this: [https://github.com/swagger-api](https://github.com/swagger-api)

Besides, it would be awesome if browser plugins could make SQRL available for
sites that don't support SQRL yet.

I haven't read the protocol specs yet - does SQRL allow metadata exchange
between the authenticating client app and the website? Especially for
registrations this might be very useful. For example, the client could suggest
a TTL for the session or provide an email address the website can use to
contact the user.

------
tdeck
Reminds me of a startup called clef. When I went to link to them, I found
they're shutting down:

[https://getclef.com](https://getclef.com)

~~~
laurent123456
I guess this kind of technology will pick up once Facebook or Google adopt it
(or, more likely, develop their own).

------
joschkadev
[https://tillmanns.me/authentication.html](https://tillmanns.me/authentication.html)

------
chuckdries
So it says SQRL is "stateless", but I'm still confused. You'd still use
cookies or JWTs to implement sessions, right? How do I actually identify the
client that I just authenticated? In other words, when the user clicks
'login,' what is actually sent to me, the nonce? Is the url in (this
graphic)[[https://www.grc.com/sqrl/sign-
algo.png](https://www.grc.com/sqrl/sign-algo.png)] the login page URL? If so,
do I have to use an intermediary cookie to remember which client I sent a
given URL to?

~~~
laurent123456
I think he means that the authentication process itself is stateless, as you
don't need to store any usernames or passwords. I don't think you even need to
store the nonce since it will still be on the page by the time the
authentication process is complete.

~~~
cm2187
What I think they mean by stateless is that the private key used for the
website is derived from the master private key and the domain name of the
website. So the only state to maintain is the master private key. There is no
need to maintain a list of what key was used for what website.

~~~
paulryanrogers
Which is its greatest weakness IMO since a compromise of the master key means
all accounts using that key are vulnerable. And one doesn't need the key
database to get it. It could be guessed.

With passwords an attacker has to guess each site independently, or gain
access to the password database and the decryption password.

IIRC the SQRL file itself is like a database of master keys so one can change
them in an orderly way. But the idea is to have only one, or a few.

~~~
cm2187
Which is why the master key shouldn't reside everywhere.

But this is no different from any other password manager. Once you have the
master password, you can access everything else.

The difference in my opinion is that because you would only leave this master
key on one device, preferably a hardware protected, encrypted device like an
iphone, stealing this key is significantly difficult. Whereas with a password
manager, you have to type your credentials on a machine open to malware and
key loggers.

------
oliver2213
I really like the idea, but the time frame of when the protocol will be
"complete" seems (as noted by other commenters here and by the fact that it
looks to have been posted in 2013) a bit sketchy. Still, I'm seriously
thinking about making server / client libraries for myself and others so this
is less of "Here's this really cool idea and a few sort-of complete
implementations", and more "Here's this really cool idea, and here's how you
can integrate it into your sites if you want".

------
homakov
Check this out - it actually has implementations -
[https://securelogin.pw/](https://securelogin.pw/)

------
4e1a
I have a backup of my SQRL keys for when this goes mainstream. I really like
the idea, but am not hopeful it will become widely adopted.

------
falsedan
Why does this need an app? Looks like it would work just as well with a
browser extension reading the QR code.

~~~
arnoooooo
Actually the QR code is not even needed then. It's just browser-generated
ids/keys.

~~~
cm2187
But there is a strong argument for storing the private key on a different
machine, particularly a disk-encrypted, app-whitelisted iphone, rather than on
an open platform likely full of malware and telemetry like a mac or a pc.

Then you need a way for your 2FA device to interact with the browser to do the
login for you. A QR code is as good as another method.

~~~
falsedan
What about a smart card then?

~~~
cm2187
Even better except that now you have to carry it around everywhere.

------
davidkhess
To me, the fatal flaw in SQRL (and options like it) has been MITM (man in the
middle) attacks. For instance:

[https://security.stackexchange.com/a/46205](https://security.stackexchange.com/a/46205)

~~~
ramriot
Which would make it no worse in that respect than anything else & in many
respects much better, please Note:
[https://news.ycombinator.com/item?id=14472929](https://news.ycombinator.com/item?id=14472929)

The use of remote QR-Code authentication is no longer a key feature here, the
expectation is that it will almost never be used unless for exceptional
circumstances.

~~~
davidkhess
Can you expand on what "Client Provided Session" means?

~~~
ramriot
Very simply:

In the browser session authentication use case, as well as a sqrl:// scheme
link being launched the browser makes a parallel internal probe and then
direct GET request to [http://127.0.0.1](http://127.0.0.1) on port 25519 which
is locked by the local client the payload of the original link base64URL is
encoded in the url, which hands over control of what follows to the client
application.

The client performs authentication as normal, but instead of the session being
updated via a browser push a redirection response is returned to it via the
client which leads to a single use very temporary and unguessable link that
kicks off the authenticated session.

Because of browsers same origin policies and other security protections we
believe it is not possible for an MITM attacker actively tunneling a valid
SQRL login page to gain access to this information.

Clearly this does rely on the browser agent upholding strict security
policies, but then if it did not you would have much bigger problems.

~~~
davidkhess
It seems like this would require native browser support because if it were
done in Javascript, couldn't the MITM be able to take the redirect response
and send it on to their backend?

If it does require native browser support, I would worry about chicken and egg
adoption issues.

~~~
ramriot
You may think that, but does not appear to be so. The response is a 302/3
redirect which automatically puts it outside the bailiwick of the attackers
scope.

Provided that is the attacker is not using same domain origin, scheme, port
etc. Which if they were you would perhaps have greater problems.

That said, we will all be testing that feature most thoroughly.

~~~
davidkhess
Unless you actually set the address bar (i.e. window.location) to
localhost:25519 I don't think this is going to work. I've used ajax with REST
APIs that return 302s and you will receive the body of the destination page as
the return value to the ajax call. The page in the window (window.location) is
not going to change. And this is of course if localhost:25519 returns the
proper CORS headers in the first place to allow the ajax GET to even occur.

I think the only way this could work is if you set the window.location to
localhost:25519 when starting the SQRL authentication. That will result in
harder UX problems to solve but it does seem feasible.

Regardless, having reviewed FIDO and the W3C Web Authentication API, it seems
to me that SQRL doesn't have a chance of seeing any wide adoption once those
two are available. They have the dual advantage of standardization and
platform control that are nearly impossible to overcome by external offerings.

------
jelv
No more username, passwords and your are in control. Seems like a perfect
protocol for login and authentication.

How will it work on mobile only world? Can this also work on iOS and Chrome
OS?

~~~
cm2187
You would typically store the private key on a single device to reduce the
risk of leaking it. Authentication on another device is done through the QR
code. Authentication on the same device is done through the SQRL app
registering a protocol. So you tap on the QR code, it opens a SQRL:// url
which opens in the SQRL app, the app authenticates, the websites redirects you
to the desired authenticated page.

~~~
jelv
So my ID's are in my SQRL app on my laptop or phone. Can I sync my ID's
between my laptop and phone? I don't want to be forced to use my phone to scan
a QR code on screen for every site..

Can 1Password implement SQRL?

~~~
cm2187
I don't know about the particulars of the app, but at the end of the day, the
only data stored in the SQRL app is the private key. All website specific keys
are derived from a combination of the domain of that website and of the
private key. So there is no need for a sync mechanism per se, outside of
originally sharing the private key.

That being said storing that key on your (encrypted) mobile only is what
protects you.

There is an option to maintain the state of which websites were used to
authenticate, but that's only to reset your access should your private key be
compromised (or mobile stolen). Then your SQRL app should sync the list of
websites with some central location. This would ensure that the day you think
the key is compromised, you can reset all access to all websites with a new
private key automatically (this is part of the SQRL protocol).

On 1Password, I don't see why not. Gibson made the protocol open source and
free.

------
ConfucianNardin
Note: This was first published in 2013 (or maybe even earlier).

It hasn't gained traction since, so it seems unlikely it ever will.

~~~
jelv
The development started in 2013, but it's, at this moment, not finished. Steve
Gibson commented that it's almost complete and is just working on the
documentation. So it's not that weird that it's not adopted in mainstream
sites.

~~~
torgoguys
Just commenting on timing here, not the pros/cons of SQRL, which is a whole
other discussion:

It's been "almost done" for a long time now. At Gibson's 2014 digicert
presentation, he said he would be able to demo it in about a week. Nope, that
initial demo didn't happen for another 6 months, IIRC. Shortly after that demo
--we're talking June 2015--the Windows client was (checking transcript)
"almost finished." Today is exactly TWO YEARS TO-THE-DAY later, and I don't
think the client is yet complete.

I'm all for doing something right, and that's his stated reason for why it's
taking so long, but it also means that based on past history, you should take
his time estimates with a HUGE grain of salt. He's slow--it has been nearly
200 weeks of time where he claims he has been working on this more-or-less
"non-stop" and that it has been his "focus."

~~~
rdsmith24
I agree, I've been hearing that this is "done" for years! He's not even
supposedly working on his main product "Spinrite" because he working on SQRL.

------
chaz6
Does this have the facility to choose an identity when logging in since you
may have more than 1 account on a site?

~~~
cm2187
I think you can achieve that in the SQRL app (I don't know if it does in
practice). The app would have multiple private keys with one flagged as
active. You would toggle which is active before reading the QR code (or
tapping on it if on the same device).

~~~
borplk
I believe technically it "computes" the private key on the fly as you need it
(it's derived from the master key plus other factors to make it unique per
site/user).

------
shardullavekar
Have a look at [https://authme.io](https://authme.io) \- we have both app and
SDK for a push notification based authentication.

Do have a look at [https://medium.com/@shardul.citrus/passwords-bad-ux-
security...](https://medium.com/@shardul.citrus/passwords-bad-ux-security-
loopholes)

P.s. I work for AuthMe.

~~~
nextlevelwizard
Seriously what even are you offering? Your web site doesn't tell me anything.
Everything is just "pattern lock" that and "pattern lock" this. Are you just
substituting passwords with freaking 9 point "pattern lock"? Because that
sounds super dangerous and weakens security significantly (and it's not like
people are going to use different patterns for all websites/services anyway)

Also your signup says "no credit card required" are you asking money for this?
Because as far as I'm aware SQRL is completely free to use.

~~~
cormacrelf
Not to mention authme.io redirects to authme.authme.authme.host. I love it.

~~~
stapled_socks
That's pretty odd. I struggle to see the point. Certainly didn't help
establish trust in the service.

------
midnitewarrior
This was posted about 4 years ago, and it was half baked and fully attacked by
wherever I saw it posted.

I was quite annoyed by it because I had a similar idea that addressed some of
this scheme's weaknesses that I was developing before this was released (half
baked!), and the negative attention this brought wasn't going to create a warm
welcome for my concept, so I dropped it.

------
sametmax
But if somebody steals your unlocked phone the person can connect to your bank
?

~~~
vim_wannabe
I'm guessing it depends on the client. Most security oriented software on
iPhone at least ask for unlock code or Touch ID when opening the app.

~~~
falcolas
You typically have to set a security code first, before those can be
requested. My memory of setting up a new phone is rusty, but I don't recall
this being a required step.

------
Numberwang
For those in Sweden(and maybe elsewhere), is this similar in any way to the
method BankID uses?

~~~
theninth
By BankID I think you are referring to "mobilt BankId"? They are both
providing 2FA, but that is where the similarities end. They solves completely
different problems.

If you use an e-mail-adress (and a password of course) to login on multiple
sites, anyone with access to those sites databases could check which services
you uses and they could collect all data from all of those databases to get
alot of information about you.

Mobilt BankId is like that but worse from a privacy perspective. It make sites
(I think, someone correct me if I'm wrong) able get, not only the information
you provided, but also tie that to your real life identity. That's great for
Skatteverket and Försäkringskassan, but for "Random Hacker Forum", it might
not be that great.

SQRL will not in itself reveal anything about your identity. Even if you use
SQRL to login in on different sites and someone had access to all of those
sites databases they would not be able to see that you use the same SQRL-
identity to login.

Also, BankID is relying on a third party for authentication where SQRL is not.

------
daveio
This can be instantly disregarded because Steve Gibson is a charlatan. He's
got a history of getting things wrong as loudly as possible in order to
generate reputation.
[http://attrition.org/errata/charlatan/steve_gibson/](http://attrition.org/errata/charlatan/steve_gibson/)

~~~
towerbabbel
It seems to be one of the immutable laws of the internet that whenever there
is a discussion of anything related to Steve Gibson someone will invariably
post the link to that attrition.org site.

If I may disregard the entire Ad hominem part and instead focus on the people
posting the link. I must wonder how many have actually read what the site says
about Steve Gibson and given some thought to what it might mean.

It records a dozen or so issues over a the last 17 years. He has been doing
the Security Now podcast since summer of 2005. That is a two hour podcast, 50
episodes a year for twelve year. That is 1200 hours of content. That is like
40 books worth. Then there is also the columns he has written and so on. 40
books attempting to explain security issues to a wider audience with only a
dozen errors seems an amazingly low error rate to me.

If you also look at what sort of errors are reported you see that some of them
seem to be more the errors of degree, rather than kind. He seems to have a
tendency to blow things out of proportion; for hyperbole. But if hyperbole is
such a deadly sin, why is their go to reference for Steve Gibson errors The
Register?!?

Now I'm sure Steve Gibson has made more mistakes than those, and the he holds
silly opinions on some things. Everyone does. But that attrition.org page does
not seem to convince me of anything aside from making me lower my esteem for
the attrition.org site.

I do wish that rather than this sort utterly lame Ad hominem attacks proposals
were judged on their own merit, but this is the internet, so maybe I shouldn't
hope for too much.

~~~
MichaelGG
Dunno, read stuff like this:

[https://www.grc.com/ssl/ev.htm](https://www.grc.com/ssl/ev.htm)

Which has the basic premise of "if you run a device completely controlled by
your company, somehow Firefox will magically have special code integrity that
IE doesn't".

~~~
tmottabr
What he is referring to is that you can add EV certs to IE via group policies.

So your company can make any site show the green ev bar in IE.

This cannot be done in any other browser so in firefox, chrome and everyone
else a green bar means a valid ev cert from a real certificate autority.

On the other hand in IE a green bar does not mean anything because group
policy can make any cert show as ev with green bar and all.

~~~
MichaelGG
And if you're running a device where other people have root, then you probably
shouldn't be trusting binaries to display certain colours.

------
HurrdurrHodor
A more viable competitor: [https://www.n-auth.com/](https://www.n-auth.com/)

~~~
cm2187
But this is a commercial solution. SQRL is an open source / free protocol.

