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 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.
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.
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.
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.
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 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.