1 of 33

Session Strength and Reauthentication

Adam Dawes (adawes@google.com)

IIW

October 2013

http://goo.gl/H2f5iY

Google Confidential and Proprietary

2 of 33

IDP’s core value is to protect account security

Google already provide sophisticated systems for authentication

Risk analysis
Login challenges
Multifactor authentication

Google Confidential and Proprietary

3 of 33

What are the security risks for being an Relying Party?

Account with IDP has been compromised

Credential theft

Password reuse
Phishing
Malware
Unauthorized machine access
Account recovery

Account is abusive

Spammy
Hijacked

Out of sync with Identity Provider

Important events IDP has learned since RP authenticated user

Google Confidential and Proprietary

4 of 33

Proposed Framework for Improving Security for RPs

Device Strength� Bind user to machine more tightly while accounting for malware and phishing�
Reauthentication � Limit risk of unauthorized machine access�
Account Quality Information� Reduce risk of accepting spammy accounts �
Alerts for Big Account Changes� Get visibility to events like change password and account suspension

Google Confidential and Proprietary

5 of 33

Framework for Session Strength

How much can RP trust the machine?

Session provenance

Level D : Basic login challenge (password); low confidence from risk system

Level C : Basic login challenge (password): high confidence from risk system

Level B : Two factor (knowledge + device) authentication and high risk score

Level A : Multifactor authentication with strong hardware or OS hooks and high risk score

Device characteristics

Device: Familiar device

Geo: Familiar geolocation

Lock : Confirmed screen lock in place on device (Android, ChromeOS only)

Google Confidential and Proprietary

6 of 33

Requirements to upgrade Session Strength to Level B or A

Level

C -> B

Level

B -> A

Verified phone
Authenticator app
Authzen enabled
Cloud biometric (voice recognition)

Security key
Device biometric

Google Confidential and Proprietary

7 of 33

RPs can see session strength

Proposed implementation- add session strength field to ID token:

{"iss":"accounts.google.com",� "at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q",� "email_verified":"true",� "sub":"10769150350006150715113082367",� "azp":"1234987819200.apps.googleusercontent.com",� "email":"jsmith@example.com",� "aud":"1234987819200.apps.googleusercontent.com",� "iat":1353601026,� "exp":1353604926 � “acr”: C.Device.Geo }

RPs can silently check session strength if they know the user’s email address

Google Confidential and Proprietary

8 of 33

RPs can ask to upgrade session strength

Proposed implementation- add session strength field to authentication request

https://accounts.google.com/o/oauth2/auth?�client_id=424911365001.apps.googleusercontent.com&�response_type=code&�scope=openid%20email&�redirect_uri=https://oa2cb.example.com/&�state=security_token%3D138r5719ru3e1%26url%3Dhttps://oa2cb.example.com/myHome&�login_hint= jsmith@example.com � gsession_strength=C

Can only request session strength auth level, not device characteristics

Google Confidential and Proprietary

9 of 33

Relying Party Session Strength Setup Flow

(No Android device)

Google Confidential and Proprietary

10 of 33

Google Confidential and Proprietary

11 of 33

Google Confidential and Proprietary

12 of 33

Google Confidential and Proprietary

13 of 33

Google Confidential and Proprietary

14 of 33

Google Confidential and Proprietary

15 of 33

Google Confidential and Proprietary

16 of 33

Google Confidential and Proprietary

17 of 33

Google Confidential and Proprietary

18 of 33

Relying Party Sign-in with Session Strength Upgrade

(Different Device; User has just gotten an Android Device)

Google Confidential and Proprietary

19 of 33

Google Confidential and Proprietary

20 of 33

Google Confidential and Proprietary

21 of 33

Google Confidential and Proprietary

22 of 33

Google Confidential and Proprietary

23 of 33

Reauthentication

Google Confidential and Proprietary

24 of 33

Reauthentication

Given a session with an acceptable strength, challenge the user to ensure another person is not using the device.

Stolen/unlocked device
Family fraud
Stranded session

Two kinds of challenges:

Cloud Test
Device Test

Google Confidential and Proprietary

25 of 33

26 of 33

RPs can ask for reauthentication

Proposed implementation

App requests reauth token request from reauth API�Can include session data to bind request to RP event
Reauth token request includes Cloud or Device reauth preference
App will send user to reauth URL with reauth token
Challenge the user

If user not registered, will be sent through registration flow
If registered, challenge user

If success, Google returns ProofToken including meta data from request
RP validates proof token with Google

Google Confidential and Proprietary

27 of 33

Reauthentication Setup Flow

Google Confidential and Proprietary

28 of 33

smiles

Google Confidential and Proprietary

29 of 33

Google Confidential and Proprietary

30 of 33

Google Confidential and Proprietary

31 of 33

Reauthentication Flow

Google Confidential and Proprietary

32 of 33

smiles

Google Confidential and Proprietary

33 of 33

Google Confidential and Proprietary