# Implementing SSE RISC Protocol for Identity providers

By Tom Sato, COO VeriClouds
[e-mail]
Date: July 25th 2022
Draft No. 2 (Soon to be updated)

## The Big Question

Let’s say that a person A has accounts at two webapps 1 and 2 and these two uses different CIAM providers, X and Y. Person A was reusing same passwords on 1 and 2. This persons password was hacked at Webapp 1, and now this person needs to protect the account at Webapp2. How could Webapp1 send a message to Webapp 2, when Webapp 1 does not know Person A has webapp 2 account?

## Overall situation ID providers are in

There are Identity providers that can issue an identity like email provider or government IDs. Then there are Identity Access Management providers that provides access for webapps. Or they could be both.

There are webapps that has its own IAM system then there are providers. Some providers are centralized and offering federated IAM service via OpenID Connect. Others have multiple of clients that they provide software as a service and each have its own instance and database, separate from each other.

The privacy policy and regulation prevent them from sharing security information on individuals without their consent. Also, most importantly, passwords are store securely either hashed or encrypted and therefore difficult to verify is the current password is in fact, breached.

## Why implement SSE?

Currently, identity is authenticated at the time of login, only. End point detection, only works at the time of the attack. However, accounts and passwords may be breached, elsewhere. First, there is no monitoring during the session or out of session, if a breach occurred. And you want to prevent attacked, before you are attacked. These breach information could come from all kinds of sources, such as threat intelligence to end point detections, but, there is no standardized mechanism to relay this security alert.

Biden Administration issued EO 14028, May 2021 and this requires, Zero Trust Principal applied to all points of end user’s lifecycle. SSE will enable ZTP, if implemented.

## Key factors

In order to have full view of these situations, here is a list of factors that needs to be taken into consideration before designing an architecture for SSE system by CIAM.

1. Discovery of the breach

- The breach was discovered by Person A

2. The breach was discovered by Webapp 1

3. The breach was discovered by CIAM X

4. The breach was discovered by third party threat intelligence

5. The breach was detected to be high probability by end point cyber security app.

2. Where was breached

1. Account

2. End point device

3. Webapp

4. CIAM

5. Network

3. What was breached

1. Password

2. FIDO Key

3. Bearer token

4. API Access token

5. Certificate

6. GIF image of ID

7. Credit card

8. etc

4. Status of breached password in question

1. Breached password is in fact the current password discovered by Webapp, or CIAM or threat intelligence

2. Status of current password is unknown because it has not been compared to breached password that was discovered or assumed.

3. Deleted password by end user

5. Who is reporting the breach?

1. Person A

2. Webapp 1

3. CIAM X

4. Third party threat intelligence

5. Third Party endpoint cyber security app

6. How it was breached

1. Person A’s passwords was breached at the end point

2. Webapp 1 using CIAM X was breached by Person A’s compromised password

3. Webapp 1 using CIAM X was hacked in entire userbase breached

4. At third party Webapp where Person A reused the password in question.

7. At what point in time CIAM Y receive the SET<compromised credential>

1. At or before a new signup when CIAM Push to CIAM X or threat intelligence to find out if there was a breach.

2. At login when CIAM Y Push to CIAM X or threat intelligence or other CIAM

3. When end user change password and CIAM Y Push to CIAM X or threat intelligence or other CIAM

4. During session when CIAM X Polls or Sendto CIAM Y

5. Out of session when CIAM X Polls or Sendto CIAM Y

6. During session and out of session when threat intelligence sends SET to CIAM Y

8. Confirmation for CIAM Y that it’s account and password of Person A was in fact breached

1. Password at Webapp 1 needs to be compared to password at Webapp 2

2. No need to compare password

3. Account was breached

9. How to compare passwords

1. Compare plain text passwords

2. Compare verification tokens of passwords at the time of login

3. Compare hashed passwords when same hashing algorism is used by CIAM X and Y

4. In case of different hashing algorithm is used by CIAM X and Y

10. SSE RISC Spec

1. Credential Compromised

2. Account Credential Change Required

3. Account Purged

4. Account Disabled, Account Enabled

5. Opt In, Opt Out Initiated, Opt Out Cancelled, Opt Out Effective

6. Recovery Activated, Recovery Information Changed

## Problems with SSE communication model

1. PUSH by receiver. Usually, it is the transmitter that is discovers the compromised and initiate to send SET <compromised credential> and not the other way round.

2. POLL. Typically, receiver do not want to send the list of entire user base to transmitter. Some have billions of end users and this would not be practical.

3. SENDTO. Not in SSE. Transmitter may not know that receiver has that person’s account.

4. Content of SET <compromised credential> does not have any description of the breach nor the content of the breach.

## Data requirements

In order for CIAM Y to take action, Y needs the following information. Most of these details are not within SSE protocol spec yet.

1. User name

2. Reason

1. Password breached noticed by CIAM X

1. How?

2. Percentage?

2. Password was found in the darkweb by Threat Intelligence

3. End point was breached an

1. Reported by end point detection

2. Reported by Person

4. Account was breached

5. Webapp was breached

6. CIAM X was breached

3. Password comparison method

1. Plain text (bad idea and not recommended)

2. Verification Token

3. Hashed password using

1. Hashing Algorithm (what?)

## Username anonymity

1. List of breached user name could be misused.

2. Standardized hashing of user name could be use by domain needs to be plain text(?).

## Password Verification Method

Transmitting and storing plain text password, where it was recovered from the darkweb or held at CIAM, is very bad idea. So, most CIAM store passwords hashed.

However, if CIAM X has different hashing algorithm from CIAM Y, then, how do you compare?

1. CIAM X Send hashed password with hashing algorithm. (This may work if CIAM Y understands the hashing algorithm and has plain text password)

2. Use common Verification Token (VeriClouds) methodology. This requires CIAM X and Y both generate and store Verification Token, when plain text password is available to process.

## SENDTO mechanism

1. Central deposit of breached username-password held by Government agency like police.

2. Send to all CIAM then on to all Webapp connected

3. Send to specific Webapp at specific CIAM

4. Question : What is the address?

## Storing data of compromised or deleted password

1. These data are useful for future signup and login to stop people from reusing

compromised passwords.

2. Question is how to store these data and until when.

3. Should there be a centralized depository of compromised or deleted passwords. This is like police record or list of stolen credit card numbers. Should governments do this.

## There are three very different identity service providers

1. Centralized Identity providers. They are like Google, Microsoft with centralized ID database

2. IDaaS providers that have many clients (enterprise and webapps). Their ID data is held at each clients.

3. Webapps and Enterprises that has their own IAM system.

## IDaaS providers are in complicated situation

Key Points

1. They have large number of clients with very different setup.

1. Large enterprise

2. Large webapp

3. Small enterprise

4. Small webapps

5. etc

Discovery of the breach

1. The breach was discovered by Person A

2. The breach was discovered by Webapp 1

3. The breach was discovered by CIAM X

4. The breach was discovered by third party threat intelligence

5. The breach was detected to be high probability by end point cyber security app.

ID Data

1. IDaaS do not have direct access to ID Data

2. ID Data are decentralized, held at clients

3. ID Data passwords are hashed

4. IDaaS has thousands of clients with billions of accounts

5. Which means that IDaaS providers needs to build a HUB like structure to support SSE security alerts for compromise.

## SSE Hub for IDAAS

1. Each IDaaS has its own unique client base and ecosystem that will need a hub like structure to service each clients. This will enable sending SETs from the HUB to clients but also, clients to share signals.

2. Each IDaaS and clients has over lapping end users, so it takes sense for IDaaS providers to share signals.

3. Interoperability between each SSE HUBs will be very important.

Tom Sato’s recommendation

Having talked to PM and engineers at IDaaS companies at Identiverse, I think someone needs to create a reference SSE-HUB.

Tom Sato [e-mail]