Your SlideShare is downloading. ×
CIS14: How I Came to Share Signals and Learned to Love my Identity System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CIS14: How I Came to Share Signals and Learned to Love my Identity System

277

Published on

Andrew Nash, Confyrm …

Andrew Nash, Confyrm

A look at how operational notifications can be aggregated, processed and shared in ways that increase the resiliency and trust of your identity ecosystem.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
277
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. How I Came to Share Signals & Learned to Love my Identity System Andrew Nash, Confyrm Inc. andrew@confyrm.com @winemaker
  • 2. Identity Ecosystem … Confyrm, Inc Attribute Exchange Attribute Providers Identity Providers Relying PartiesUser Authorization Manager Validation Service Verification Service Trust Eval Service Authentication Service Personal Date Store
  • 3. When the Ecosystem happy path fails … Operational events occur that are not accounted for by identity protocols In aggregate, we all know more … … than any one single entity or view point Could we … share operational events that enhance the integrity of the ecosystem and protect the user while providing privacy controls…? Confyrm, Inc
  • 4. Google knew before AOL 7/2/13 Commercial in confidence – do not redistribute
  • 5. The Account Reset Pattern Confyrm, Inc
  • 6. Trusted Communications Channels —  Only communications paths are: —  Email —  SMS —  Assumed level of Trust —  “real security” for high value accounts devolves to controls on trusted channels —  Every IAM mechanism leverages them: —  Username / Password —  Multi-factor Authentication —  Biometrics —  SSO Technologies Confyrm, Inc
  • 7. New nomenclature … Confyrm, Inc IDP A Email Svc RP x IDP B RP x RP z IDP A Email Svc Event Parsing Service Signal Multicast Service SIgnal Manager Signal Recipients Event Publishers
  • 8. Signal Manager —  Trusted intermediary —  Shields Account Identifiers & Event Publishers —  Real world identities out of scope —  Identification is limited to Account Identifiers —  Not usernames —  PII is not stored or shared —  Policy based event distribution/transformation —  Events are artifacts of operational identity ecosystem
  • 9. Confyrm Sygnal Manager Confyrm, Inc fp { e } = s events signals policy
  • 10. Event Notifications - ATO Confyrm, Inc an@gmail.com an@gmail.com an@aol.com an@BofA.com an@gmail.com an@aol.com BofA AOL Google an@gmail.com an@ BofA.com an@ aol.com f p { e } = s Sygnal Manager
  • 11. Event Notifications – Password Change Password := new_password an@gmail.com an@gmail.com an@eBay.com eBay Google an@gmail.com an@ ebay.com f p { e } = s Sygnal Manager Confyrm, Inc
  • 12. Account Query Confyrm, Inc an@gmail.com an@gmail.com an@eBay.com an@aol.com an@Yahoo.com eBay Yahoo! Google an@gmail.com an@ gm ail.com an@ aol.com f p { e } = s Sygnal Manager an@aol.com AOL an@aol.com
  • 13. Recent Events —  OIX UK Govt Shared Signals Whitepaper, Sept ’13 —  Google Shared Signals Presentation —  October Internet Identity Workshop —  UK IDAP Shared Signals Discovery Project —  Event & Signal Catalogues —  Architecture, Service API and IDP Integration —  Privacy & Legal Frameworks —  Alpha project late Summer —  NSTIC Shared Signals Project —  Selected as finalist from 42 submissions —  Final set selected in Sept Confyrm, Inc
  • 14. PROTECTING THE IDENTITY ECOSYSTEM Identity Ecosystem Collaborate to Protect Maintain Integrity
  • 15. Shared Signals in IDAP Context Confyrm, Inc Verizon MyDex DigIdentity Post Office Experian IDPs IDAP Hub f p { e } = s Sygnal Manager Verizon MyDex DigIdentity Post Office Experian UK Email Providers
  • 16. To Anticipate Some Questions … •  Events are Account level activities •  Events & Signals are very simple structures : •  AccountID, EventType •  AccountID, SignalType [, PublisherClass] [, Priority] •  Event Publisher & Signal Recipient AccountID are different •  Signal Recipient AccountID is already known •  Does not use transactional information, authentication activities, session activity or application activation Confyrm, Inc
  • 17. Confyrm, Inc
  • 18. Signal Processing —  Loosely coupled Input and Output event streams —  Asynchronous event notification eliminates polling overheads —  Policy controlled signal handling —  Event transformation —  Signal urgency —  Delivery thresholds —  Signal content —  Obfuscation techniques —  “All Clear” reset notifications —  Signal Types: —  Password reset —  Account recycling —  Account takeover —  Account suspension —  Configurable signal classes —  Optional User Notification (policy based) 7/2/13 Commercial in confidence – do not redistribute
  • 19. Use Cases —  Account Takeover —  Password Change —  Account Reuse —  Recent account creation —  Mobile device purchase —  Stolen identity – cross IDPs Confyrm, Inc
  • 20. ATOs are a fact of normal life Confyrm, Inc
  • 21. Risky Account Changes and Account Quality Adam Dawes (adawes@google.com) IIW October 2013 http://goo.gl/MpTVyG
  • 22. IDP’s core value is to protect account securityAlready provide sophisticated systems for authentication •  Risk analysis •  Login challenges •  Multifactor authentication
  • 23. What are the security risks for being a Relying Party?Account with IDP has been compromised o  Credential theft §  Password reuse §  Phishing §  Malware §  Unauthorized machine access §  Account recovery Account is abusive o  Spammy o  Hijacked
  • 24. Big Account Changes are a risk for RPs Password change at IDP 1.  User gets hijacked but doesn’t know it 2.  Hijacker logs into site/app via federated login (and sets up a mobile app) 3.  Hijacker starts abusing user’s account on RP 4.  User discovers they have been hijacked; changes password on IDP 5.  Hijacker still has valid session on RP and continues to abuse account Security best practice: on password change, RP should revoke: •  All cookies for active web sessions
  • 25. Big Account Changes Challenges There are other IDP events that an RP should know about •  Suspected hijacking [prompt for password change next login] •  Account recovered •  Account deleted •  Account suspended •  Account recycled •  OAuth revocation of App •  Expired token
  • 26. •  Google is RP for many Google Apps customers via SAML o  Enterprises frequently require their users to change password (and sometimes detect an employee’s account was hijacked) o  Enterprise/School accounts are not usually “accounts for life” and eventually get terminated •  Google is “RP” to other mail providers for accounts o  Account recycling - Hotmail, Yahoo! etc. •  Are there already patterns we can follow? o  When do we revoke OAuth access to Gmail mobile app when an account is deleted? o  Are there mechanisms for this already specified in SAML? §  SCIM can signal an employee has left the company, is that a start? Google would like to be subscriber of changes too
  • 27. OIDC Session Management is not enough If the RP keeps login state synced with IDP, that should work right? •  Not all RPs or IDPs want to have their session state synced •  Mobile apps use OAuth, don’t see session state changes. Which session would you want to tie it to anyway? •  Hijacker can sign up for subscriptions (or other background activities) on RP that do not track session state
  • 28. Google to provide pub/sub feed for account changesPublish “risky events” to RP endpoint when Google detects them •  Site registers notification URL •  Site receives notifications for users where it has an active OAuth grant

×