3 ms·
Very little of that article is applicable. The website is served over HTTPS, the browser has a crypto API now. The encryption in this project decreases the impa
by minitech 7y ago
Very little of that article is applicable. The website is served over HTTPS, the browser has a crypto API now. The encryption in this project decreases the impact of any future compromise of the server (if a share link is never visited post-compromise, it’s safe) and makes it necessary for an attacker to show their hand by serving malicious code to the client. (With browsers as they are now, that can be made hard to detect, but it’s a start. There’s always the risk of serving it up to someone who’s logging every response.)
- sneak 7y agoAll the other js resources on the page can still backdoor the app, though, and exfiltrate your keys. SRI and no longer executing javascript served with the right content-type in an img src is helpful along these lines, but even with SRI on every script tag, the sub-scripts pulled in from the integrity-checked third party js can pull in arbitrary further resources which can then overwrite your functions to steal your keys. Even a strict CSP doesn't totally close the hole. It's sort of crazy how difficult (that's a euphemism—I would term it "impossible") it is to even attempt to secure browser-based crypto, over and above the normal challenges involved in crypto implementation. I wouldn't use clientside js crypto for anything more secret than a grocery list.