Ah, right. My bad. I mistakenly believed that a thread creator had deletion rights. But would lead to havoc. 
SQRL client feature comparison
- Thread starter DetlevSchm
- Start date
- Watchers 10
Added feature 0 "Show domain name at login".
I already assumed, that the GRC client has this feature.
Next update will additionally have the features renumbered from 0-17 to 1-18.
I already assumed, that the GRC client has this feature.
Next update will additionally have the features renumbered from 0-17 to 1-18.
Last edited:
Oh, yes... and it's CRUCIAL that a client shows the SQRL authentication domain in a way that will be clearly seen. That's the EASIEST of all possible SQRL spoofs and it's been a source of much debate and concern!
- added feature "19|Request: Lock account"
- added feature "20|Request: Unlock account"
- added feature "21|Request: Remove account"
- added feature "22|Request: Alternate ID"
- again assumed that the GRC client offers all of these features
- re-arranged and renumbered lines, numbering will or might vanish once the iOS column is filled
Yep. The GRC client is where all of these features originated.
(And thanks for this this valuable work!
(And thanks for this this valuable work!
G
Gristle
Guest
If the browser knows the domain in the URL bar, can't this spoof be stopped by comparing the domain of the SQRL code and the domain of the URL bar? If the root domain isn't the same, it's clearly a spoof.
That's 100% true, @Gristle , and this is a benefit that a SQRL web browser extension has that external clients do not. I struggled to get that information for my own Windows desktop client, since it SHOULD have been present in the HTTP Referer: header of the incoming CPS jump. But the localhost server is not HTTPS and any login page will be HTTPS (as will nearly all pages now). And the browser rules state that the Referer header MUST be stripped when moving from any secured to non-secured page.
The only glitch here is what constitutes the "root domain". The fact that you phrased it that way show that you understand the issue. But non com, edu, gov, net, etc, domains sometimes have two 'dots' rather than just one before the "root" domain. Take "register.co.uk" for example. If we were not smart, then any *.co.uk domain could spoof us.
G
Gristle
Guest
Thanks for confirming Steve. Seems that browser vendors and browser extensions would have a significant advantage in this regard! I'm sure you'll agree that putting the burden on the user to make sure the domain matches what they expect is a step that might easily be overlooked, especially after getting used to just skipping right past it. Here's to hoping that browser vendors and/or extension developers will adopt SQRL!
I assume that the reason the localhost server is HTTP is that the browser would thusly have to trust a self-signed localhost HTTPS cert, which it wouldn't trust by default. But doesn't that also mean that a malicious actor on localhost could get up to mischief with the unencrypted CPS traffic?
I assume that the reason the localhost server is HTTP is that the browser would thusly have to trust a self-signed localhost HTTPS cert, which it wouldn't trust by default. But doesn't that also mean that a malicious actor on localhost could get up to mischief with the unencrypted CPS traffic?
I mentioned one time putting the certificate fingerprint into the QR code so the external device, if it receives a cert from the website with a different fingerprint, will know something's wrong. I can't remember the reason for not doing that now.
G
Gristle
Guest
That's a really cool idea, but I think that would be spoofable unless the fingerprint portion of the code were encrypted or signed. Meaning, amaz0n.com takes the QR code from amazon.com, reads the contents of the code, creates a duplicate code, but replaces the fingerprint portion from amazon.com's cert and inserts the fingerprint from amaz0n.com's cert, and shows that to you. I guess the SQRL QR code would have to have some kind of hashed checksum to prevent tamper.... ugh. That gets complicated I think. I'm not a crypto expert, so I might be totally wrong.
That might have been it: trying to get it to work unspoofably might be more trouble than it's worth.That's a really cool idea, but I think that would be spoofable unless the fingerprint portion of the code were encrypted or signed. Meaning, amaz0n.com takes the QR code from amazon.com, reads the contents of the code, creates a duplicate code, but replaces the fingerprint portion from amazon.com's cert and inserts the fingerprint from amaz0n.com's cert, and shows that to you. I guess the SQRL QR code would have to have some kind of hashed checksum to prevent tamper.... ugh. That gets complicated I think. I'm not a crypto expert, so I might be totally wrong.
- added synonym list
- added 23 - 26
- rephrased 19-26 adding footnotes (2) and (3)
- updated Linux column
I assume, that for a server's "managed shared access" the client is not involved, because the invitation-based joining
an account is handled solely by the server.
G
Gristle
Guest
why not put this into a google doc spreadsheet? I'd love to be able to contribute to the iOS column, but I'm not sure how.
I'm still new enough to ask dumb questions, hehe!, so here goes...
I somehow got the feeling that CPS was never going to work on mobile apps. I don't even know what CPS stands for (I presume not Chicago Public Schools). So maybe iOS and Android could be "no" for those?
Where does one go if one wished to completely understand each of these features?
If there's a new feature, like for a mobile client to be more annoying about validating the domain if it's never "seen" the domain before, do we have a place to put and discuss those ideas that might be good or might be bad, but aren't implemented anywhere?
I somehow got the feeling that CPS was never going to work on mobile apps. I don't even know what CPS stands for (I presume not Chicago Public Schools). So maybe iOS and Android could be "no" for those?
Where does one go if one wished to completely understand each of these features?
If there's a new feature, like for a mobile client to be more annoying about validating the domain if it's never "seen" the domain before, do we have a place to put and discuss those ideas that might be good or might be bad, but aren't implemented anywhere?
Not I, but if someone else wants to do that, go ahead
.Just post here and refer the row number, like:
iOS:
- 5 yes
- 12 no
I will then update the OP.
CPS should be active wherever you have same-device login. So if you're visiting a SQRL-enabled site on your mobile phone, and you tap the link, the mobile SQRL app on that phone will be able to authenticate with CPS.
By the way, it stands for Client Provided Session, because the SQRL app gets a genuine link from the website and redirects the user away from the site he was on. So if that ended up being a phishing site, the user is protected.
G
Gristle
Guest
Yes. And has Steve has pointed out, CPS is the secret sauce of SQRL that is probably the first or second most important part of SQRL. All clients will have CPS, but only for same device login.
Adding just a bit to what Shane and Gristle have written, for the benefit of those who are in the process of coming up to speed on all of the (admittedly many) aspects of SQRL's design: The other thing that CPS provides, in addition to a link which redirects the user's browser to the proper website, is the "CPS" token which is literally, a "client provided session." In other words, the CPS URL carries and contains a cryptographically strong "nonce" which the SSP API has never issued before and never will again. This nonce was provided to the user's SQRL client by the SSP API after authenticating, so the SSP API "knows" who it has given this nonce to. The SQRL client redirects the user's browser -- with that nonce -- back to the authentic website. But the nonce means nothing to the website. So it then takes that nonce and privately queries the SSP API asking "Hey, who is this that has just given me this nonce?" to which the SSP API, who absolutely knows who since it just freshly authenticated the user before handing out the nonce, replies with the user's proven SQRL ID.