This document discusses how HTML5 features can be used for authentication purposes and addresses some security challenges. It describes APIs like local storage, canvas, geolocation, and notifications that could be leveraged for authentication factors like passwords, patterns, and one-time passwords. However, it also notes risks like storing sensitive data on devices, spoofing locations, and notifications not being reliable. The document advocates using HTML5 responsibly and understanding privacy and user behavior when designing authentication solutions.
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Owasp2013 johannesullrich
1. HTML5: Risky Business or Hidden
Security Tool Chest
Johannes B. Ullrich, Ph.D.
jullrich@sans.edu
2. About Me
• Dean of Research,
SANS Technology Institute
• Living in Jacksonville FL
(aka Southern GA)
• SANS Internet Storm Center
https://isc.sans.edu
• Created DShield.org
• Instructor for SANS
• Past: Physicist, Web Developer
Hosted by OWASP & the NYC Chapter
3. What is HTML5
• Collection of JavaScript APIs supported by
some modern browsers in some ways and
sometimes they even work.
• Features to enable modern desktop like
applications and support mobile devices
• 5th Revision of the HTML Standard
4. What is this talk about?
• Ideas to improve security by using HTML5
responsibly
• What are some of the security challenges that
HTML5 addresses well (or doesn’t)
• What are some of the limitations we have to
consider
5. Authentication
• Exclusive vs. Inclusive Authentication
Methods:
– Inclusive:
Proof the identity
of the user
– Exclusive:
Disproof the identity
of the user
6. What the Factor?
Segway: Multi Factor Authentication
• Single Factor: Password
• Two Factor: Password AND (Token|Biometric)
• 1 ½ Factor: Password and Cookie
• ½ Factor: Password
OR (Token|Biometric)
8. Local and Session Storage
• New JavaScript API to store data on client
• Protected by “same origin”
• Local Storage:
– No defined expiration
– Accessible by all browser windows
• Session Storage:
– Expired when window is closed
– Scope limited to current window
9. Local Storage: Persistent
Cookie
• Alternative to Flash cookie for “1 ½ Factor”
login
• Part of an “Evercookie”
• Can be used for good (additional
authentication) or evil (more user tracking)
• Exposed to XSS attacks
• Similar to cookies in scope and security
10. Session Storage: Identifying
users
• Can be used to store session token
• Breaks CSRF (good!)
• User is logged out when they close the
browser window (not entire browser)
• Multiple users can use the same browser (is
this a good thing?)
• Easier log out, more secure session
tracking, can be used alongside cookies.
11. Risks
• Risks:
Storing too much data on the client!
Can’t enforce “secure” transmission over SSL
Can’t protect from JavaScript/XSS (no httponly)
Examples:
– storing confidential data on mobile devices
– Pushing data to the client the client is not
authorized to see.
12. Can I use it?
http://caniuse.com/#feat=namevalue-storage
13. Canvas
• Allows drawing in the browser
• Interactive image applications
• Can be used for graphical login schemes
– CAPTCHAs
– Pattern based login
14. Image Login
• Display image, user identifies features
• Done in Windows 8/RT for mobile login
(“Pattern Login”, “Picture Password”)
Image:
Microsoft
15. “Connect the Dots”
• Implemented in Android
• Good user acceptance for mobile login
• No good studies yet as to how users select
patterns
Image:
Extremetech.com
16. Demo
• Demo: “Connect the Dots” for the web
• http://authonthemove.com
• See Github for code repository
18. Geolocation
• JavaScript API provides access to devices built
in sensors like GPS
• Can be very accurate
• Can also be spoofed easily
Image: Mozilla.org
19. Geolocation for Authentication
• Only useful on mobile devices
• Can be used to exclude users, but not to
replace traditional authentication
• Observe sudden changes in location
• Combine with careful browser fingerprinting
techniques
21. Media Capture
• aka getUserMedia/Stream API
• Limited support (Chrome, Firefox, Blackberry)
• Some potential for biometrics:
– Face recognition
– Hand signals / gestures
– Fingerprint?
23. Difficulties
• Hard to acquire sufficient detail
• So far, in particular on mobile devices, more of
a gimmick then a serious authentication
feature
• Possibility to use “finger print”, but current
cameras not sufficient to acquire image
25. Accelerometer
•
•
•
•
•
•
•
Only useful for mobile devices
Move the phone in a pattern to authenticate
Detect step/walking pattern
Detect if user/phone is at rest or on the move
Can be spoofed (but not readily)
Not easy to reproduce
Adding sensors like compass may help.
26. Can I use it?
http://caniuse.com/#feat=deviceorientation
27. Notifications
• Popup Notifications sent by the server to
notify the user
• Initiated by server
– Local Notifications: Require browser to be
open, widely supported
– Push Notifications: Safari Only
28. Bad stuff happened!
• Notify the user of security relevant events:
– “Someone is trying to log in as you”
•
•
•
•
User needs to accept notifications
Notifications no 100% reliable
Not “out of band” (can be faked, intercepted)
Safari Notifications may be useful for one time
passwords (OTP)
29. Can I use it?
http://caniuse.com/#feat=notifications
30. Encryption
• Client side encryption
• Allows encryption of specific sensitive fields
(e.g. payment data, passwords)
• Intermediate services (proxies, web services)
don’t need to know the information
• Upcoming: CryptoAPI (June 2013)
http://www.w3.org/TR/WebCryptoAPI/
• Until then: https://www.pidder.de/pidcrypt/
31. Client side password hashing
• Server sends random “nonce” as part of login
form.
• Client calculates hash from password/nonce
• Passes hash to server
• Server verifies hash
• Advantage: Server never gets to know the
“real” password.
32. Signup
•
•
•
•
•
Use enters password
Client hashes password
Password hash transmitted to server
Salt: Username? Provided by server?
Changing password: Same procedure, salt may
change.
33. Summary
• Lots of cool and useful tools in HTML5
• Use them as appropriate
• “HTML5” itself isn’t the risk. Bad coding is the
risk
• Understand privacy issues
• Understand user behavior
• Share your code an experiences (OWASP!!)
