JavaScript Cryptography
Co-founder whiteout.io
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?
DEMO
Whiteout Mail
Architecture
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
Thank You
Blog post to these slides:
tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/
JavaScript Cryptography
By tanx
JavaScript Cryptography
Lessons learned and best practices for JavaScript cryptography
- 1,428