Next Steps toward More Trustworthy Interfaces, continued

1. Next Steps toward More Trustworthy Interfaces, continued Burt Kaliski, RSA Security2nd TIPPI WorkshopJune 19, 2006 Also includes presentations from FSTC and W3C

2. Agenda • Recent industry activities around user authentication • How to get more trustworthy user interfaces • Next steps

3. Recent Industry Activities • A growing chorus (and calendar) … • June 2005: 1st TIPPI Workshop • October 2005 – May 2006: FSTC Better Mutual Authentication project • October 2005: FFIEC guidance on user authentication • March 2006: W3C workshop on Web authentication • June 2006: 2nd TIPPI Workshop • July 2006: Proposed IETF session on Web Authentication Resistant to Phishing (WARP)

4. FSTC Better Mutual Authentication Project • The Financial Services Technology Consortium (FSTC) ran a project on Better Mutual Authentication (BMA) from October 2005 – May 2006 • Dan Schutzer, executive director of FSTC, has summarized the findings in a presentation he prepared for this workshop: BMA Roadmap: A Summary of the BMA Findings • FSTC is considering a second phase of the project

5. W3C Workshop on Web Authentication • The World Wide Web Consortium (W3C) organized a workshop on Web authentication in March 2006 • The team has summarized its work in another presentation prepared for this workshop: W3C Engagement in Web Security • Follow-on work is also being considered in this organization

6. IETF Web Authentication Initiative • Sam Hartman, co-Security Area director in the IETF, is proposing a new project on Web Authentication Resistant to Phishing (WARP) • From his Internet-Draft at http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-00.txt: “This memo proposes requirements for protocols between web identity providers and users … Websites must never receive information such as passwords that can be used to impersonate the user to third parties. Browsers should perform mutual authentication and flag situations when the target website is not authorized to accept the identity being offered …” • Session proposed for July 2006 IETF meeting

7. FFIEC Guidance • The Federal Financial Institutions Examination Council (FFIEC) in October 2005 issued general guidance that banks should employ more than “single-factor authentication” for high-risk transactions • Quoting from the guidance at http://www.ffiec.gov/pdf/authentication_guidance.pdf: “… Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks.” • Guidance is not technology-specific; organizations are expected to comply by end of 2006

8. How to Get More Trustworthy Interfaces • An authenticationagent observes what the application and user are doing and protects the user • e.g., PwdHash • An authentication service also responds to (authorized) requests by an application • Proposal: Establish a trustworthy user authentication service as the primary interface between the user and applications w.r.t. user authentication • Trustworthy = User has assurance that (a) this service is interacting with user (b) on behalf of an authorized resource • minimum: authentication data are protected from misuse

9. How to Get There • Architecture: • Where should it go? • What should it do? • Standards: • How do you use it? • service interfaces, e.g., “Run authentication mechanism” • authentication mechanism types: “username/password,” “OTP token,” “PKI token”, etc. • Requirements and use cases • Analogy: Media players

10. User Authentication Architecture Today PC or mobile phone browser VPN other apps. generic operating system services userinterface deviceinterfaces credentialstore

11. User Authentication Architecture Today PC or mobile phone browser VPN other apps. PKCS #11, CAPI userinterface deviceinterfaces credentialstore

12. A Better Architecture for User Authentication PC or mobile phone browser VPN other apps. trustworthy user authentication service userinterface deviceinterfaces credentialstore

13. In Conclusion  • Industry should standardize on a single authentication mechanism • Industry should support multiple authentication mechanisms, but standardize on the user interface • Industry should support multiple authentication mechanisms and user interfaces, and standardize on the service interface • Result: A platform for innovation in trustworthy interfaces for user authentication, and better security  

14. Next Steps for TIPPI Proponents • Continue to advance trustworthy interface concepts within the various industry initiatives • Collaborate on architecture and standards proposals • Contribute to the 3rd TIPPI Workshop next June!

15. Contact Information • Burt KaliskiVice President of Research, RSA SecurityChief Scientist, RSA Laboratoriesbkaliski@rsasecurity.comhttp://www.rsasecurity.com/rsalabs

16. Additional Presentations • BMA Roadmap: A Summary of the BMA Findings • W3C Engagement in Web Security

17. BMA Roadmap: A Summary of the BMA FindingsDaniel Schutzer, Executive Director FSTC

18. Summary: Key Themes • Mutual authentication is vital • A necessary first step to improving online safety • The best way to improve customer confidence in the online channel • Mutual authentication is strategic • Not just a technology or operational play • Understand you own posture with regard to risk, operational outsourcing, cooperation with other FIs • The consumer/customer is the main story • Consumer fears drive regulatory pressure • Consumer confidence essential for success of online channel • Consumer convenience drives or inhibits adoption of new solutions • Customer support costs are significant now and in the future

19. Talking to consumers about authentication • “You need better security for online financial services” • “Why? I’m not liable!” • “You mean this online stuff isn’t safe enough already?” • “Fine, as long as it doesn’t cost me anything and is just as convenient” • “We’re changing our approach to online security” • “Are you really my FI? Your message sounds like a phishing scam to me” • “What was wrong with the old way?” • “I just want to get to my account—why are you making me jump through all these hoops?” • “Is this because of the latest merger? You’ve already messed up my old services and made me change things” • “Here’s your new secure authentication device.” • “What am I supposed to do with it?” • “What does this do for me?” • “What if I don’t want to use it?” • “No way—have you seen what I already have to carry around?” • “I already have a handful of these things—can’t I just use one I’ve already got?” • “But I need one for my computer at the office” • “This is more of a hassle than it used to be—can I go back to the old way?”

20. N W E S Four Directions to Approach Authentication AlternativeChannels Electronic Credentials SharedSecrets ContextualAnalysis

21. Authentication challenges associated with delegation of authority • Informal delegation of authority by retail customers (e.g., sharing passwords or auth devices) leads to a variety of exposures • FIs cannot distinguish the principal customer from a delegate • All-or-nothing access for delegates—i.e., customer can’t restrict what their delegate can do via online services • Rescinding authority granted to a delegate is difficult • In the real world, fraud by “friends and family” is a significant problem • Delegation of authority to third party services presents other challenges • Introducing new authentication measures can “break” legitimate access by third party financial services • Some existing access by third party services may represent compliance challenges with current regulatory guidance • Sharing of authentication mechanisms across multiple FIs can significantly increase exposures when customers delegate authority to others

22. Near-term steps for the vendor community • Incorporate mutual authentication into products and services • Wherever possible, provide options to support two-way authentication • Where not possible, integrate products or services into solutions that facilitate mutual authentication • Improve interoperability of products and services • Authentication techniques and devices that interoperate with standard services • Services that support various authentication techniques and devices • Adopt standards that facilitate interoperability • Introduce services that integrate multiple authentication techniques into comprehensive solutions • Address customer support for the consumer population at large • For vendors of OSs, browsers, and other Internet applications • Overhaul and substantially improve usability of security measures at all levels • Simplify security configuration management for end users • Substantially improve security of computing platforms used by consumers

23. W3C Engagement in Web Security • Public Workshop March 15/16, NYC, onUsability and Transparency of Web Authentication • http://www.w3.org/2005/Security/usability-ws/report • 41 position papers, 70+ attendees • All major browser vendors • Security vendors • Large content providers (financial services and others) • Researchers (including some speaking at TIPPI)

24. Workshop Goal & Lessons • Practical security: What can help users make the right decisions? • ... when you can't avoid letting them decide ... • Lessons • Web authentication is broken today. • The problem isn't solved by any player alone. • There are both short-term and long-term contributions.

25. Suggested Approaches • Tame the browser: Restrict content's ability to manipulate the user interface. • Authenticate the interface to the user. • Trusted paths and login ceremonies • Customized user interfaces • Richer metadata • Logotypes • Trust seals with browser support • Content labeling

26. Suggested Approaches (2) • Let software, not users, manage credentials. • User-centric Identity management. • Or maybe just better password managers? • Zero-knowledge password proofs. • Use context known to software to assist users. • Distinguish known and unknown sites • Petnames

27. Requirements • The Web runs on more than just Personal Computers • Device independence – how to do security indicators on constrained devices? • Mash-ups and RESTful web services • Today, they just ask for passwords they shouldn't know. • Delegate authorization decisions.

28. Please join the conversation • Workshop follow-up list:http://lists.w3.org/Archives/Public/public-usable-authentication/ • W3C is pursuing discussions in several directions: • Taming the browser -- “secure chrome” • Richer security context information • Enabling client-side password management • You should expect to hear more from us soon. • For more information, contact: • Karen Myers, Development Officer, karen@w3.org