3 ms·

These are great points, but allow me to add to them: 2. This is similar to what I do with my ssh keys today. I mean yeah the wait time is a bit eh and you are

These are great points, but allow me to add to them: 2. This is similar to what I do with my ssh keys today. I mean yeah the wait time is a bit eh and you are right that people will likely end up degrading their security in order to mitigate it, but what's the alternative? Perhaps better education is in order. 3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions? Also, would you clarify what you mean by xsrf bypassing tls, as I don't understand how that would happen and it certainly sounds quite troubling. 5. This isn't really much more involved than secure user/pass auth, and less complex than oauth for example.

nly 12y ago
> 3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions? Not really. There's no way for the app to know whether the particular QR code it just scanned came via a browser session protected by TLS, using a particular CA chain, connected from a particular IP, at a particular time, or with a particular session id. Even if all that information were encoded in to the QR dataset by the server, and digitally signed, it still need to be verified and counter-signed by the browser before being displayed for scanning. All you're really doing is QR encoding a certificate chain at that point... but in order to do that your browser needs to be cryptographically paired with the app. What you have right now is TLS CA-certified confidence going in to the browser and "the user thinks this QR code is cool" level confidence going in to the app. The user is a poor substitute for a certificate chain. > Also, would you clarify what you mean by xsrf bypassing tls Sorry. I meant XSS. If you can inject script in to a TLS protected SQRL page it's game over (you just replace the QR code with one from http://192.168.1.5/MrEvilProxyOnTheSameLAN/dynamically_generated_qrcode.png http://192.168.1.5/MrEvilProxyOnTheSameLAN/dynamically_gener...) then the IP enforcement, as currently proposed, will pass assuming everyone on that LAN has the same external IP. IP bonding is just a lousy way to emulate a decent session layer.... which is ultimately what HTTP needs to nail this down once and for all.

nly 12y ago

> 3 & 4. Aren't these solved by requiring ssl, which should be in place anyway for user-based interactions? Not really. There's no way for the app to know whether the particular QR code it just scanned came via a browser session protected by TLS, using a particular CA chain, connected from a particular IP, at a particular time, or with a particular session id. Even if all that information were encoded in to the QR dataset by the server, and digitally signed, it still need to be verified and counter-signed by the browser before being displayed for scanning. All you're really doing is QR encoding a certificate chain at that point... but in order to do that your browser needs to be cryptographically paired with the app. What you have right now is TLS CA-certified confidence going in to the browser and "the user thinks this QR code is cool" level confidence going in to the app. The user is a poor substitute for a certificate chain. > Also, would you clarify what you mean by xsrf bypassing tls Sorry. I meant XSS. If you can inject script in to a TLS protected SQRL page it's game over (you just replace the QR code with one from http://192.168.1.5/MrEvilProxyOnTheSameLAN/dynamically_generated_qrcode.png http://192.168.1.5/MrEvilProxyOnTheSameLAN/dynamically_gener...) then the IP enforcement, as currently proposed, will pass assuming everyone on that LAN has the same external IP. IP bonding is just a lousy way to emulate a decent session layer.... which is ultimately what HTTP needs to nail this down once and for all.