Re:Bitshares Login
by nly on Tuesday December 23, 2014 @08:59PM
(#8791202)
> 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_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.
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_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.