"doing crypto in the browser is like performing
open heart surgery in a sewage plant"
Security is About EcOnomics
JS CRYPTO - Attack Surfaces
- Browsers are complex, each works differently
- XSS (cross site scripting)
-
No constant time algs (pure js crypto)
- No cross-platform key storage (iOS keychain)
Native Crypto - Attack Surfaces
- No view src for installed apps
- Memory safety (Heartbleed)
- App codebase per platform
=> LOC correlate to the # of bugs in software.
The biggest risk is human error.
Can we serve all platforms
with one codebase?
But why not via Web Server?
-
Drive by Web designed to run untrusted code
- Served code can change at any time
- Server can compromise individual users
=> you're trusting the web server with your data
Threat Modeling
Is this a service...
I trust with my data ?
=> Web server deployment
- Elster Online (taxes)
- Netflix (premium content)
I don't trust (completely) with my data ?
=> Installed / Packaged App
- Whiteout Mail (my email)
- Spideroak (my files)
- Exposes native crypto to JS
- AES, RSA, SHA, ...
- Encrypt and decrypt
- Hashing, sign and verify
- Generate and store keys
JS Security - Best Practices (1)
-
HSTS (HTTP Strict Transport Security)
- Certificate pinning
-
CSP (Content Security Policy)
-
'use strict'; and jshint in CI
-
JSON.parse (never eval)
JS SECURITY - BEST PRACTICES (2)
-
Escape strings before rendering
- Native
WebCrypto
(constant time)
- Engineering best practices (testing, reviews)
-
Security audits by independent pros
-
Open source the (crypto) code