RISC

Risk and Incident Sharing and Coordination

​

Adam Dawes (adawes at google.com)

​

http://goo.gl/aksGhx

Account breaches can result in cascading failures

http://goo.gl/aksGhx

Internet is built on web of dependencies

If an account from an email provider/identity provider is hacked, relying parties are at risk:

​

Sites where the hacked user:

• Registered for an account with their email address
• Did federated sign-in
• Did OAuth access

​

Additionally, attackers can easily register for new accounts on relying parties while account is taken over

http://goo.gl/aksGhx

RISC Working Group background

• Google presents strawman for coordination at IIW Oct ‘14�
• Birds of a feather group meetings begin Dec ‘14 (AATOC)

Google, Yahoo, Microsoft, Facebook, LinkedIn, Twitter, Paypal, Ping Identity, AOL, Confyrm, Peercraft, Nomura�

• Agreed upon charter with the OIDF�
• Creation of WG

http://goo.gl/aksGhx

Workgroup Charter

Objective

• Determine ways for providers to share security event info to prevent cross-app attacks and to help users regain access to lost accounts

​

Scope and Deliverables

• Security Event Definition (non-spec)
• Security Event Privacy Guidelines (non-spec)
• Trust framework for data sharing (non-spec)
• Communications mechanisms (spec)

http://goo.gl/aksGhx

Security Events

Account Status Change

• Hijacked
• Suspended (by user, admin, provider)
• Deleted (by user, admin, provider)
• Reissued (by admin, provider)

​

Credential Change

• Password changed
• Authentication mechanism changed
• Recovery method changed

​

​

http://goo.gl/aksGhx

Receiving RISC events

• Send to all “known applications” to the service provider
• OAuth grants, Email confirmations
• How to get retroactive relationships�
• Create a trust framework for self-assertion
• Standards around uses of information (security only)
• Only assert users you have
• Legal declaration
• Difficult to scale

http://goo.gl/aksGhx

​

​

THANKS

http://goo.gl/aksGhx

​

​

​

​

APPENDIX

http://goo.gl/aksGhx

RISC is a way for providers to work together to make it harder for bad guys

​

Focus:

​

• What data should be shared�
• Who are the relevant parties�
• What are the privacy implications to sharing�
• What mechanisms should be used to share

http://goo.gl/aksGhx

Possible Options: What data should be shared?

Raw events

• Reset password
• Force password reset
• Account recovered
• Account deleted
• Account suspended
• Account recycled
• OAuth revocation of App
• Expired token
• New payment method?
• New shipping address?

Recommendations

• Terminate existing sessions
• Update identifier
• Suspicious activity

http://goo.gl/aksGhx

Who are relevant parties to this information?

• Who should be eligible?

IDP -> RP

RP -> IDP

RP -> RP

3rd parties?

​

• Who is interested?

​

• What actions would you take with the info? Who would you trust?

​

• Should reciprocity be required?

​

http://goo.gl/aksGhx

What are the privacy implications of sharing?

• What are the use cases where sharing this information would harm the user?�
• What kind of user consent/notification is needed?
• Should user have option to notify when practical?
• Does it matter if data is an event or recommendation?
• Would standardization make it easier?

​

http://goo.gl/aksGhx

What mechanisms should be used to share?

Proposal:

Publish security recommendations to qualified third party’s abuse endpoint

• Use well-known
• Site receives IDToken notification for users where it has an active OAuth grant

​

Proposed Feed� {"iss":"accounts.google.com",� "sub":"10769150350006150715113082367",� "aud":"1234987819200.apps.googleusercontent.com",� "time":1353604926� “reco”:”terminateSession”}

​

​

http://goo.gl/aksGhx

Next steps

• Google forges ahead and see what happens�
• Standardize transport and semantics

http://goo.gl/aksGhx

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
• All OAuth tokens for mobile apps

​

But how is an RP to know that a user changed their password???

http://goo.gl/aksGhx

Google would like to be subscriber of changes too

• Google is RP for many Google Apps customers via SAML
• Enterprises frequently require their users to change password (and sometimes detect an employee’s account was hijacked)
• Enterprise/School accounts are not usually “accounts for life” and eventually get terminated�
• Google is “RP” to other mail providers for accounts
• Account recycling - Hotmail, Yahoo! etc. �
• Are there already patterns we can follow?
• When do we revoke OAuth access to Gmail mobile app when an account is deleted?
• Are there mechanisms for this already specified in SAML?
• SCIM can signal an employee has left the company, is that a start?
• What security practices do enterprises use to protect themselves now?�

http://goo.gl/aksGhx

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

​

​

http://goo.gl/aksGhx

Implicit RPs can subscribe too

• When user enters recovery email address, do federated login verification instead of email verification to get OAuth token
• If sites ONLY do email + password login, no way for IDP to know to notify them

​

http://goo.gl/aksGhx

What RPs to notify?

• IDP can remember what RPs a user visited and notify them
• IDP can also let user view what RPs were recently visited either after account hijacking, or to try to detect a hijacking
• But then IDP (Google) has to “track” user activity on RPs to provide security
• What about the theories that IDPs should not track RPs? Is Security or Privacy more important for average user?
• IDP could let users disable security. Or users can choose IDPs who only support the mode they prefer.
• Should RPs trust those RPs/accounts with disabled security? Do they need to provide manual mechanism to invalidate all old cookies/tokens?

http://goo.gl/aksGhx