4 ms·

Serious request, what do you think about unhosted client side crypto? https://youtube.com/watch?v=WTPimUSIWbI https://youtube.com/watch?v=WTPimUSIWbI

by diafygi 10y ago

nickpsecurity 10y ago
Thanks for bringing the unhosted trend to my attention. I haven't heard of it. I'm a bit skeptical about the graphic in the front page given applications often need to perform computations on the data itself. There's probably something in the site that addresses that. I'll read it in a few days and then maybe look at your tool. Btw, you need to correct the WebCryptoAPI link in "Security and Philosophy" part of this page: https://github.com/diafygi/byoFS https://github.com/diafygi/byoFS Clicking it gives me nothing. Copy-and-pasting the link results that resembles spyware. I think it's just missing a colon after http is all.
pfg 10y ago
I think something like the self-hosted version (file:///) of this is getting close to something I'd consider safe enough. The backdoor problem from my previous post obviously isn't exclusive to web apps - a large chunk of software we use day to day performs updates automatically, and no one's going to reverse-engineer everything after each update. That being said, the average native app implementing E2E crypto is probably still safer as of today for a number of reasons: Binaries are typically signed by the developer, which isn't something you usually see in a web app using Web Crypto. Signing keys are easier to protect from unauthorized access, compared to your entire web stack. With native apps, you tend to have far more control over code changes. You can chose your own update schedule and review new software versions for any critical component. A typical web app could change the code on every request. Web apps also make it a lot easier to pull off a targeted attack. There's also simply a larger attack surface in general. Anything from XSS to phishing is much easier to pull off in a web app (though, as iMessage showed us, it's not quite that simple). Just think about how much effort browser plugins for password managers have to go through to prevent users from accidentally entering their master passphrase in some phishing form. @chrisfosterelli mentioned the app cache approach of circumventing this - I guess we'll end up with some kind of trusted zone for crypto-related code in browsers, maybe with code signing and what not, sooner or later, and that might get us fairly close to the security of native apps. I don't think we're quite there yet. PS: Thanks for writing acme-tiny!

Serious request, what do you think about unhosted client side crypto? https://youtube.com/watch?v=WTPimUSIWbI https://youtube.com/watch?v=WTPimUSIWbI

by diafygi 10y ago

Serious request, what do you think about unhosted client side crypto? https://youtube.com/watch?v=WTPimUSIWbI https://youtube.com/watch?v=WTPimUSIWbI

nickpsecurity 10y ago

Thanks for bringing the unhosted trend to my attention. I haven't heard of it. I'm a bit skeptical about the graphic in the front page given applications often need to perform computations on the data itself. There's probably something in the site that addresses that. I'll read it in a few days and then maybe look at your tool. Btw, you need to correct the WebCryptoAPI link in "Security and Philosophy" part of this page: https://github.com/diafygi/byoFS https://github.com/diafygi/byoFS Clicking it gives me nothing. Copy-and-pasting the link results that resembles spyware. I think it's just missing a colon after http is all.

pfg 10y ago

I think something like the self-hosted version (file:///) of this is getting close to something I'd consider safe enough. The backdoor problem from my previous post obviously isn't exclusive to web apps - a large chunk of software we use day to day performs updates automatically, and no one's going to reverse-engineer everything after each update. That being said, the average native app implementing E2E crypto is probably still safer as of today for a number of reasons: Binaries are typically signed by the developer, which isn't something you usually see in a web app using Web Crypto. Signing keys are easier to protect from unauthorized access, compared to your entire web stack. With native apps, you tend to have far more control over code changes. You can chose your own update schedule and review new software versions for any critical component. A typical web app could change the code on every request. Web apps also make it a lot easier to pull off a targeted attack. There's also simply a larger attack surface in general. Anything from XSS to phishing is much easier to pull off in a web app (though, as iMessage showed us, it's not quite that simple). Just think about how much effort browser plugins for password managers have to go through to prevent users from accidentally entering their master passphrase in some phishing form. @chrisfosterelli mentioned the app cache approach of circumventing this - I guess we'll end up with some kind of trusted zone for crypto-related code in browsers, maybe with code signing and what not, sooner or later, and that might get us fairly close to the security of native apps. I don't think we're quite there yet. PS: Thanks for writing acme-tiny!