3 ms·

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:/

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 9y ago
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 9y ago
  Can you expand on what "Client Provided Session" means?
  - ramriot 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        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.
zxcvbn4038 9y ago
I'm still digesting the documentation but it looks like it would be susceptible to replay attacks also. But if all the web transactions were happening over TLS with PFS, and everyone is validating certificates, I think that would be good enough.

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 9y ago

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 9y ago
Can you expand on what "Client Provided Session" means?
- ramriot 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.

zxcvbn4038 9y ago

I'm still digesting the documentation but it looks like it would be susceptible to replay attacks also. But if all the web transactions were happening over TLS with PFS, and everyone is validating certificates, I think that would be good enough.