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

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]

[email protected]@aol.com

[email protected]@[email protected]

BofA AOL

[email protected]

[email protected] an

@ao

l.com

fp{ e } = s

Sygnal Manager

Event Notifications – Password Change

Password :=new_password

[email protected]

[email protected]@eBay.com

eBay

[email protected]

an@

ebay

.com

fp{ e } = s

Sygnal ManagerConfyrm, Inc

Account Query

Confyrm, Inc

[email protected]

[email protected]@eBay.com

[email protected]@Yahoo.com

eBay Yahoo!

Google

[email protected]

[email protected] [email protected]

fp{ e } = s

Sygnal [email protected]

AOL

[email protected]

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