Binary State of Authentication by Parul Jain

More than just being

signed-in or signed-out

Parul Jain, Architect, Intuit

@ParulJainTweety

Why do we care?

TRUST &

SECURITY

EASE OF

ACCESS

Can’t eliminate friction? Delay it

Authentication Levels to

balance security and usability

Delightful product

experience

Authentication

Username

Password

Sign In

Signed In

Not Signed In

Authentication – Signed In or Not –

Example1

Sell an item

Place Ad

Username

Password

Signed In

Not Signed

In

Sign In

Browse OLX for used products

Authentication – Signed In or Not –

Example2

Browse apps on App Store

Install App

New App on Device

Username

Password

Signed In

Not Signed

In

Install App

Sign In

Why Authenticate?

Authentication is required to establish trust

Is trust binary - Trust you fully or Not at all

Degrees of trust - Factor of time and situation

Trust you for this but not for that

Didn’t trust you earlier but trust you now

Authentication Levels

Authentication is not binary

Authentication Assurance Levels (AAL)

Adaptive - Change with time and situation

Authentication Assurance Levels (AAL)

Less Trust

Submit

Enter OTP

Authentication Level 1

Authentication Level 2 More Trust

AAL – Example1



My bank account

Transfer Money

Payment


Usernam

ePasswor

dSign In

My bank portal

Sign In

AAL – Example2



Transfer Money

New Payment Instrument


Usernam

ePasswor

dSign In

Mint application

Sign In

Enter OTP

Submit

Access my personal finances

AAL – Example3



Browse products on Amazon

Track Order

Or

Checkout

View/Place Order

Username

Password

Sign In

MFA and AAL Relationship

AAL is the outcome.

MFA is the mechanism

MFA provides layered defense

Binary Authentication

Multiple Authentication Assurance Levels

LIC: Binary without MFA

Google: Binary with MFA

Amazon: Multiple Levels with MFA

Intuit: Multiple Levels with MFA

How to determine the AALs?

REQUIRE

Based on

sensitivity of

the APIs

ADAPT

Based on

trust in the

user with

time

ASSIGN

Based on

factors of

authentication

ASSIGN an AAL

ASSIGN REQUIRE

ADAPT

• What I know

• password

• What I have

• OTP

• What I am

• fingerprint

• Other

• Federated

Based on factors of authentication

ADAPT to an AAL

ADAPT

Based on trust in user with time

REQUIRE

Change in

• Device

• Geolocation

• IP address

• Velocity of use

• Behavioral Biometrics

• Anomalous behavior

ASSIGN

REQUIRE an AAL

REQUIRE

ADAPT

Based on sensitivity of the APIs

• Secret

• OAuth Client Secret

• Highly Sensitive

• Money movement

• Financial data

• Sensitive

• Personal

information

• Other

• Public information

ASSIGN

AAL Determination

Good

Step-up

Step-up

Good

Good

Step-up

Good

Good

Good

Trust in user

authentication

Sensitivity

of the APIs

Low High

Low

High

Component Interaction

Identity

Service

s

APIs

Client

1. Sign in

2. Session with an

AAL

4. Verify

3. Access

Resource

5. Step-up URL

6. Redirect for Step-

up

7. Step-up

8. Higher AAL

Determine

AAL

Remembe

r the state

Check

expected

AAL

Client

Widget

Configuration

APIs

Create the verify request

Verify with expected AAL

Identity Services

Authn Service

Risk Engine

Sign-in

Verify

Device,

IP, geo,

time, …

Get Risk

Score

Feedbac

k

ML Model

Real time Risk Score

UNIVERSAL STRONGAUTHENTICATION –

FIDO AS A STANDARD

Fast Identity Online (FIDO)

FIDO Protocols

Public Key cryptography

UAF – Universal Authentication Framework

• Password less UX

• Local device with UAF stack installed

• User presents a local authentication

U2F – Universal Second Factor

• Standalone U2F device - USB/NFC/Bluetooth

• Physical keychain with multiple keys – one for each origin

• Built-in support in web browsers

UAF

Src: https://fidoalliance.org/specifications/overview/

UAF - Registration

User Device

FIDO Client

Win, Mac,

iOS,

Android, …

FIDO Authenticators

User

Agent

Browser

, App,

…

Identity Provider

Web

App

FIDO

Server

1. Legacy Auth +

Initiate Registration

2. Registration

request

+ Policy

3. Enroll user

+ New Key Pair

4. Registration

response +

Attestation

+ User’s public key

5.

Validate Response +

Attestation

Store user’s Public Key

UAF - Authentication

User Device

FIDO Client

Win, Mac,

iOS,

Android, …

FIDO Authenticators

User

Agent

Browser

, App,

…

Identity Provider

Web

App

FIDO

Server

1. Initiate Authn

2. Authn request

+ Challenge +

Policy

3. Verify User and

unlock private key

4. Authn response

signed by user’s

private key

5.

Validate Response using

user’s Public Key

U2F

Src: https://fidoalliance.org/specifications/overview/

Summary

As developers we have thought of

authentication as a binary switch

We need to start thinking about the degree and levels of trust

Incorporate AAL into the design

thinking

AAL will help us in balancing security vs usability

Deliver delightful experience to

customers

Thank you

Binary State of Authentication by Parul Jain

Technology

Transcript of Binary State of Authentication by Parul Jain