cis14: how i came to share signals and learned to love my identity system
DESCRIPTION
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.TRANSCRIPT
How I Came to Share Signals & Learned to Love my Identity System
Andrew Nash, Confyrm Inc.
[email protected] @winemaker
Identity Ecosystem …
Confyrm, Inc
Attribute Exchange
Attribute Providers
Identity Providers
RelyingPartiesUser
AuthorizationManager
Validation Service
Verification Service
Trust Eval Service
Authentication Service
Personal Date Store
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
Google knew before AOL
7/2/13 Commercial in confidence – do not redistribute
The Account Reset Pattern
Confyrm, Inc
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
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
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
Confyrm Sygnal Manager
Confyrm, Inc
fp{ e } = sevents signals
policy
Event Notifications - ATO
Confyrm, Inc
[email protected]@aol.com
[email protected]@[email protected]
BofA AOL
@ao
l.com
fp{ e } = s
Sygnal Manager
Event Notifications – Password Change
Password :=new_password
[email protected]@eBay.com
eBay
an@
ebay
.com
fp{ e } = s
Sygnal ManagerConfyrm, Inc
Account Query
Confyrm, Inc
[email protected]@eBay.com
[email protected]@Yahoo.com
eBay Yahoo!
[email protected] [email protected]
fp{ e } = s
Sygnal [email protected]
AOL
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
PROTECTING THE IDENTITY ECOSYSTEM
Identity Ecosystem Collaborate to Protect Maintain Integrity
Shared Signals in IDAP Context
Confyrm, Inc
VerizonMyDexDigIdentityPost OfficeExperian
IDPsIDAP Hub
fp{ e } = s
Sygnal Manager
VerizonMyDexDigIdentityPost OfficeExperian
UK Email Providers
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
Confyrm, Inc
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
Use Cases � Account Takeover
� Password Change
� Account Reuse
� Recent account creation
� Mobile device purchase
� Stolen identity – cross IDPs
Confyrm, Inc
ATOs are a fact of normal life
Confyrm, Inc
Risky Account Changes and Account Quality
Adam Dawes ([email protected]) IIW
October 2013 http://goo.gl/MpTVyG
IDP’s core value is to protect account security Already provide sophisticated systems for authentication
• Risk analysis
• Login challenges
• Multifactor authentication
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
Out of sync with Identity Provider o Important events IDP has learned since RP authenticated user
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
• Auth tokens for mobile apps
But how is an RP to know that a user changed their password???
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
• New payment method?
• New shipping address?
• 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?
o What security practices do enterprises use to protect themselves now?
Google would like to be subscriber of changes too
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
Google to provide pub/sub feed for account changes Publish “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