1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org SSSL: Server Side Secure Login Utility to Phish-Protect your Website Ronen Margulis (joint work with Prof. Amir Herzberg) Bar Ilan University maronen1@gmail.com 6 Sep 2009

2. OWASP 2 SSSL: Agenda  Intro – Phishing risks in spite of SSL  Current Defense Mechanisms & Experiments  SSSL Motivation & Demo  SSSL Details & Risk analysis

3. OWASP 3 Phishing Risks  Phishing: stealing user’s credentials (password)  Typically by:  Send (spoofed) email to user  User clicks on link in email, reaches spoofed site  User enters password…  Common Attacks:  Wrong URL attacks  Homographic: submitweb.com vs. submitvveb.com  Misleading: submitweb.c6.com vs. c6.submitweb.com  Correct URL attacks  MITM, e.g. via WiFi  DNS Poisoning (Pharming), e.g Kaminski’s attack

4. OWASP 4 Phishing – How to Prevent?  Detect, block phishing email  Detect, block phishing site (blacklists)  Many phishing sites are short lived  blacklists might not help  Prevent exposure of password to spoofed site  But doesn’t SSL already do this??

5. OWASP 5 Phishing Attacks in spite of SSL  Wrong URL with no SSL  http://submit-web.org vs. https://submitweb.org http://submit-web.orghttps://submitweb.org  SSL, wrong URL with a valid certificate  https://submit-web.org vs. https://submitweb.org https://submit-web.orghttps://submitweb.org  SSL, corrupted certificate  SSL, valid certificate published by Phisher’s CA  Browser will ask user… will user approve? Notice?  Experiments: Users do not notice!!

6. OWASP 6 SSSL: Agenda  Intro – Phishing risks in spite of SSL  Current Defense Mechanisms & Experiments  SSSL Motivation & Demo  SSSL Details & Risk analysis

7. OWASP 7 Current Defense Mechanisms – Browser  None (‘classical’ browser indicator only)  Display name of site & CA (from certificate)  Display user-selected text for site

8. OWASP 8 Current Defense Mechanisms – Site  Site Identificator  text  image  Selected during registration to site  Can be passive/interactive  Advantage: User (probably) won’t submit password if identificator doesn’t exist  Disadvantage: One extra click for interactive  Login bookmark – Presented by Ben Adida  User must click on bookmark to login  Advantage: Wrong-URL, no-SSL attacks irrelevant  Disadvantage: The Bookmark…

9. OWASP 9

10. 10

11. OWASP 11

12. OWASP 12 Login Bookmarks – details  Server generates special bookmark per user  User ‘drags’ bookmark into browser  Or automatically installs using javascript  To login, user must click on bookmark  Bookmark contains token for 1st authentication  User enters password  Password used for 2nd authentication  Only If both authenticators are correct the user logs in

13. OWASP 13 Setting up the Bookmark  Registration process similar to other sites  Confirmation email sent to the user contains a link to a bookmark creation page  will add the bookmark with a secret token  The secret token is always sent via a secondary channel other then the web! (SMS is also possible instead of email)

14. OWASP 14 SubmitWeb: Realistic Phishing Experiment [Dvorkin+Herzberg]  The Framework  Real-use assignment submission system  Long period repetitive web and email activities  Very few ‘attacks’  Student population: ~500  The Experiments  Each student randomly assigned a defense mech.  Randomly (and very rarely) attacked  The system measured detection rates  Bookmark testings focused on response to email

15. OWASP 15 SubmitWeb: Detection Rates for Identificators

16. OWASP 16 Submitweb: Login Bookmark Results  (only) 59 phishing emails with links were sent  15 to bookmark users, 44 to other users  Bookmark reduced following links, success:  Login bookmark mechanism increases user awareness against phishing attacks PopulationMails sent Links followed % followed% spoof success Bookmark users15213±14%7±10% Other users441534±11%18±9% All users591728±9%15±7%

17. OWASP 17 SSSL (Server Side Secure Login)  A site-based solution to protect the site’s users  Combines Login Bookmark & Interactive Image  Doesn’t rely on browser Add-ons  Since we can’t control their deployment  Simple, elegant and secure  Easy to deploy on different websites

18. OWASP 18 SSSL: Agenda  Intro – Phishing risks in spite of SSL  Current Defense Mechanisms & Experiments  SSSL Motivation & Demo  SSSL Details & Risk analysis

19. OWASP 19 SSSL Motivation  Easy Integrated & Free toolkit  Why not use just interactive custom image?  Detection rates are still ~80-90%  Why not use just login bookmark?  users might follow links to spoofed sites and submit their password  secret token remains secret, but..  password itself is critical

20. OWASP 20 SSSL Motivation – continue  Interactive custom image and login bookmark complete each other  Bookmark prevents surfing to a spoofed site  Custom image helps identifying a spoofed site  Each protect a different secret  Bookmark protects the token  Custom image protects the password  According to experiments – each are likely to succeed  All of the above suggest SSSL’s defense is strong!

21. OWASP 21 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password

22. OWASP 22

23. OWASP 23

24. OWASP 24

25. OWASP 25

26. OWASP 26

27. OWASP 27

28. OWASP 28

29. OWASP 29

30. OWASP 30

31. OWASP 31

32. OWASP 32

33. OWASP 33

34. OWASP 34 Usability Issues – Users  Bookmarks are easy to install in any browser  To all users?  Can be synchronized in several browsers and/or computers  Is this option common? Does users know this option?  Are not likely to be deleted, unlike cookies  Need bookmark for each site protected by SSSL

35. OWASP 35 Usability Issues – Users  Annoying to click the bookmark and image?  Less typing to do – bookmark contains username  Details later  Keeping registration email helps bookmark creation on multiple computers  If Alice looses the email – the website can send it again after asking her some identification questions

36. OWASP 36 Usability Issues – Site Admins  SSSL is a Free Utility  Easy to Read and Deploy in short time  Small amount of Code  ~100 lines of PHP (5.2.8) code as the backend  ~200 lines of Wrapping HTML code (for the demo)  ~100 lines of Javascript code + an hmac library implementation  Site Admins are encouraged to integrate SSSL  Suggestions for improvements are welcome

37. OWASP 37 SSSL: Agenda  Intro – Phishing risks in spite of SSL  Current Defense Mechanisms & Experiments  SSSL (Server Side Secure Login) – and enhancement to SSL  SSSL Details & Risk analysis

38. OWASP 38 How can the secret token be stored and sent over the network  In a cookie  In a GET parameter https://site.com/login?token=Thttps://site.com/login?token=T  In the Fragment Identifier https://site.com/login#[Token] https://site.com/login#[Token]  used to designate portion of page https://site.com/page#paragraph https://site.com/page#paragraph  browser scrolls to the appropriate location – if exists  changing fragments does not cause page reload  used in slide presentations, page scrolling without reload  never sent to the server but accessible from JavaScript

39. OWASP 39 How can the secret token be stored and sent over the network – continue  The secret token has to be stored in the browser and be sent over the network in the most secure way  Where can the token leak from?  MITM  Cookies  Token in the bookmark, as part of the URL  The address bar  The browser’s history  The HTTP Referrer Header  Cache Proxies/Web Server Logs  Assumption: use SSL  Automatically terminates MITM and the Referrer header threats

40. OWASP 40 Designing how the secret token should be stored and sent over the network Leakage ThreatsMethod MITM, XSS, shoulder surfing, history, Referrer Header, Caches/Logs Cookies over SSL MITM, XSS, shoulder surfing, history, Referrer Header, Caches/Logs GET parameter over SSL MITM, XSS, shoulder surfing, history, Referrer Header, Caches/Logs Fragment Identifier over SSL

41. OWASP 41 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password https://mysite.com/login.php#[username|token]

42. OWASP 42 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password 1.Javascript deletes the fragment identifier from the address bar and history and stores it in a variable 2.Fills in the username in the login page 3.The page doesn’t reload

43. OWASP 43 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password hmac token (username)

44. OWASP 44 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password

45. OWASP 45 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password Javascript displays hidden password text field

46. OWASP 46 The SSSL Protocol AliceBrowsermysite.com types mysite.com GET /login.php You Should login via your bookmark clicks bookmark secret token login.php + custom image You Should login via your bookmark clicks image enables password submission submits password password hmac token (username|password)

47. OWASP 47 User Awareness to Custom Image  Users might click any image presented to them  Can show the user a (small) set of images (~3-5) along with the custom image  user must click his correct custom image from the set of images  May improve user awareness  Use moving (‘animation’) gif images to increase awareness

48. OWASP 48 Resistance to Specific Attacks  Spoofed site  user follows link but token remains secret  user sees no custom image  password remains secret  Replace bookmark  replacing the bookmark does not reveal token  user sees no custom image  password remains secret  Spoofing the Browser Interface  Opening a new window with a fake bookmarks bar containing a fake bookmark  Fake bookmarks bar does not reveal token  user sees no custom image  password remains secret

49. OWASP 49 Resistance to Specific Attacks (cont.)  Overriding Page Unload  window.onuload = function(){ window.location = ‘https://evil.com/stay-here’; }  token remains secret since window.location yields current site  Alice doesn’t see her username automatically filled in, and doesn’t see her custom image  password remains secret

50. OWASP 50 Resistance to Specific Attacks (cont.)  Explicit bookmark theft  With unload overriding an attacker can convince Alice of a technical problem and ask for her bookmark  Alice needs to “make an effort” and manually copy it from the properties of the bookmark  Fragment identifier is shown in the address bar for a few milliseconds only  token, password exposed  Site should educate users to never give away the bookmark data, esp. when the custom image isn’t presented

51. OWASP 51 Resistance to Specific Attacks (cont.)  Attacking email account  Exposes token  Password to the email account might be the website’s password  If not, attacker retrieves the image  Then perform a phishing attack to retrieve the password  Using the victim’s computer  Token and image exposed, password OK  Attacker needs to perform a phishing attack to retrieve the password  Malware on victim’s computer  Bookmarks (and thus token) are exposed  Password can be key-logged

52. OWASP 52 Resistance to Specific Attacks (cont.)  Pharming Attack (correct URL, redirection to spoofed site)  no SSL - won’t work  SSL, spoofed site has corrupted certificate (or from a phisher’s CA) and the user doesn’t notice the browser warning:  hmac token (username|password) exposed to attacker  MITM can replace script and read token, password themselves

53. OWASP 53 SSSL Limitations  Javascript required  Sometimes disabled by users for security  Site can ask user to enable javascript or allow him to connect with a different mechanism (like interactive image only)  Vulnerable to Pharming attacks with bad certificate and Malware

54. OWASP 54 Conclusions  SSL in not enough  use SSSL !!  SSSL is a simple and elegant solution to defend website’s users from phishing  combines a login bookmark and an interactive custom image to improve security  Can be tried at: https://submitweb.org/SSSL/https://submitweb.org/SSSL/  Source code can be downloaded at: https://submitweb.org/downloads/SSSL https://submitweb.org/downloads/SSSL

55. OWASP 55 Future Plans  Running a pilot of an SSSL-protected website  More experiments  More data, more confidence  Compare detection rates between the following groups:  SSSL users  Bookmark Login Users  Interactive Custom Image users  Control group users (no indicators)  Design and implement a (secure) method for password recovery for SSSL-protected sites

56. OWASP 56 Thank You!! Questions/suggestions are welcome: maronen1@gmail.com