"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