Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WebHack #13 Web authentication essentials

168 views

Published on

Authored and presented by Boaz Yaniv.
https://webhack.connpass.com/event/88962/

Published in: Technology
  • Be the first to comment

WebHack #13 Web authentication essentials

  1. 1. WEB AUTHENTICATION ESSENTIALS
  2. 2. PASSWORDS CAN BE LEAK
  3. 3. SESSIONS CAN BE HIJACK
  4. 4. END OF THE AGE OF MONOLITH S
  5. 5. Web 1.0
  6. 6. SHA-2 IS NOT E
  7. 7. SALT IS NOT ENOUGH
  8. 8. 23 BILLION PASSWOR
  9. 9. USE SLOW ALGORITHMS ▸scrypt ▸Argon2id ▸PBKDF2 ▸bcrypt ALREADY TOO OLD:
  10. 10. YOU ARE CAREFUL… OTHER DRIVERS A
  11. 11. PASSWORDS CAN BE LEAK
  12. 12. OVER 60% REUSE THEIR PAS
  13. 13. bill.brown@gmail.com : TellNo1 fakeaccount@hotmail.com : verysecret zerocool@myserver.net : Z3r0d4y$ ❌ ✅ ❌
  14. 14. COUNTERMEASURES BOT PROTECTION SERVICES
  15. 15. COUNTERMEASURES DETECT SUSPICIOUS LOGINS▸ Browser Fingerprinting ▸ GeoIP
  16. 16. COUNTERMEASURES SLOW THE ENEMY DOWN ▸ CAPTCHAs ▸ Proof of Work
  17. 17. MULTI-FACTOR AUTHENTICATION SMS CODES ✔ Well-recognized ✔ No special hardware required ✔ Services like Twilio �Cumbersome �Requires a mobile number �Multiple vulnerabilities TOTP ✔ Easy to use ✔ No special hardware required ✔ Standard �Requires an app �Requires scanning QR codes �So-so security
  18. 18. MULTI-FACTOR AUTHENTICATION FIDO ✔ Plug and click! ✔ Passwordless authentication (UAF) � Mobile, Biometric, etc… �Many versions �Limited browser support �Theoretical support is theoretical
  19. 19. MULTI-FACTOR AUTHENTICATION WEB AUTHENTICATION API✔ Based on FIDO 2 ✔ All FIDO Hardware ✔ W3C Standard �Browser support still lacking �Complex! Library support immature Promising, but not ready
  20. 20. AND TOKENS SESSION
  21. 21. SESSIONS AND TOKENS SERVER-SIDE SESSIONS ▸ Complex state ▸ Multi-page form values ▸ Shopping cart ▸ Navigation information ▸ Smells like an Anti-pattern!
  22. 22. SESSIONS SESSIONS ARE USER HOSTILE ‣ User often cannot ‣ Share links ‣ Press back button ‣ Open tabs ‣ Annoying warnings ‣ Expire and delete user work!
  23. 23. SESSIONS AND TOKENS SERVER-SIDE SESSIONS ▸ Complex state ▸ Multi-page form values ▸ Shopping cart ▸ Navigation information ▸ Smells like an Anti-pattern! ACCESS TOKENS ▸ Lightweight ▸ Only keep auth state ▸ User ID ▸ Expiration date ▸ Scopes / Permissions ▸ State doesn’t change after issue VS.
  24. 24. BEARER TOKENS WHY NOT ACCESS COOKIES? ▸ Cookies are implicit ▸ Extra overhead ▸ Vulnerable to CSRF ▸ … CSRF tokens required ▸ Modern APIs can be explicit
  25. 25. BEARER TOKENS STATEFUL ▸ Token is unique ID ▸ Contents kept in DB ▸ Revocation is easy ▸ DB access on every call ▸ Harder to scale STATELESS ▸ Signed contents ▸ Optionally encrypted ▸ How to revoke? ▸ Blacklist: Same as DB? ▸ Bloom filters? VS. MISNOMER WARNING
  26. 26. BEARER TOKENS: OAUTH 2.0 OAUTH 2.0 ▸ Architecture not protocol ▸ Multiple flows ▸ Bearer token header ▸ Refresh token OFTEN MISUNDERSTOOD
  27. 27. BEARER TOKENS: OAUTH 2.0 AUTHENTICATION FLOWS CLIENT CREDENTIALS ▸ For authenticating clients ▸ Simplest flow ▸ Can replace with basic auth AUTHORIZATION GRANT ▸ For server side apps ▸ Client secret required ▸ Prevents hijacking code
  28. 28. BEARER TOKENS: OAUTH 2.0 AUTHENTICATION FLOWS IMPLICIT GRANT ▸ For SPA clients ▸ Access token can be hijacked ▸ Use URL fragment ▸ Only use HTTPS ▸ Protect against XSS ▸ Encrypt access token (not standard) PASSWORD GRANT ▸ Client has the password ▸ First-party mobile apps ▸ First-party login page PKCE ▸ Third-party mobile apps
  29. 29. BEARER TOKENS: OAUTH 2.0 REFRESH TOKENS
  30. 30. BEARER TOKENS: OAUTH 2.0 REFRESH TOKENS REFRESH TOKENS ARE NOT ▸ Eternal tokens ▸ Long-lived access token ▸ Low-privileged access token for older sessions ▸ Eternal tokens or Eternal service? You can’t have both! ▸ What’s the point? ▸ Access tokens have timestamps
  31. 31. BEARER TOKENS: OAUTH 2.0 REFRESH TOKENS REFRESH TOKENS ARE MEANT FOR REVOCATION ▸Issue very short access tokens ▸Refresh them constantly ▸Access DB to check revocation only on refresh ▸Return new access and refresh tokens
  32. 32. ACCESS TOKEN TTL = TIME TO REVOKE REFRESH TOKEN TTL = BLACKLIST
  33. 33. BEARER TOKENS: OAUTH 2.0 REFRESH TOKENS HOW TO KEEP SESSIONS FOREVER ▸ Balance CVR and security ▸ Set a realistic lifetime for your refresh tokens ▸ Store only blacklist of revoked refresh tokens
  34. 34. SHOULD I DO ALL OF THIS ON MY OWN?
  35. 35. SOLUTIONS THIRD-PARTY PROVIDERSa.k.a Social Login ✔ Easy and Free ✔ Sign-up not required (CVR up) �Privacy issues (CVR down) �Give up control of userbase �Still need to implement sessions Do not use as only method
  36. 36. SOLUTIONS: IDENTITY AS A SERVICE FULL-FLEDGED SOLUTIONS ▸ IDaaS + API Gateway Combo ▸ Can be white-labeled ▸ Can handle everything: e.g. Sessions, MFA, Revocation ▸ Your apps don’t need to know anything about authentication
  37. 37. SOLUTIONS: IDENTITY AS A SERVICE EXAMPLE ARCHITECTURE
  38. 38. SOLUTIONS: IDENTITY AS A SERVICE NOT SUCH A BAD IDEA ▸ Cheaper than do-it-yourself ▸ Better security ▸ Spirit of *aaS WOULDN’T WORK FOR ME ▸ Existing system ▸ Vendor lock-in ▸ Future flexibility is held prisoner
  39. 39. SOLUTIONS: FRAMEWORKS FRAMEWORKS ▸ Heavyweight ▸ Different levels of comprehensiveness ▸ Devise + Pundit is amazing ▸ If you can live with RoR
  40. 40. SOLUTIONS: API GATEWAYS AND PROXIES API GATEWAYS ▸ Strong Open-Source Solutions: Kong, Tyk, WSO2 ▸ Great for microservices ▸ Complicated to maintain ▸ May kill performance AUTHENTICATION PROXIES ▸ Lightweight alternative for API Gateways ▸ Can run as sidecars ▸ Need to write your own ▸ No mature third-party solutions
  41. 41. FIN

×