[Openid-specs-risc] "Credential compromise" event discussion tomorrow

Tue Mar 16 21:46:45 UTC 2021

This thread is about use case A) – a credential is found on the dark web. I will send a separate email about the other use case B) - Transmitter considers cred compromised based on their heuristic.

Matt, all good questions. Responses below:

  1.  Is the service de-duping scan results on its end?
     *   Yes, the identity threat intelligence services dedupe the data. They also maintain time stamps, such as ‘first seen,’ and ‘last seen.’ Of the services I’m familiar with all of them dedupe the data.
  2.  Would you emit the plaintext password in the event?
     *   Based on the previous discussions in the group we decided not to cover the password transmission as part of this spec, but to leave it up to the transmitting and receiving parties to enter separate agreement that defines a method for transmission of the password. If a receiving party thinks information about the user name is sufficient there will be no need for such additional agreement. Our company’s recommendation is to factor the password as part of the decision. There are several methods this can be done. If there is an interest in the group, I can explain.
  3.  I presume the event would include an event_timestamp value.
     *   This is a good suggestion. I will add it to the event code. It will be helpful in the case where the receiving party is not factoring passwords. If the process factors passwords then this attribute will have less value as ‘there are no old passwords – only those that work and those that don’t.’
  4.  I presume the event would include an event_timestamp value
     *   Yes, there will be event timestamp. It will need to have the value of ‘first seen.’ We also need to have a value for ‘last seen.’ Such info will be able to show how far ago this credential ceased to exist. If it is still available the current date will be used.
  5.  Would applications be able to subscribe to events for all sites, or just those proven to be “theirs”?
     *   Applications will be able to subscribe to events for their domains. For example, Salesforce.com will be able to subscribe for events related to salesforce.com domain across all data breaches. This will cover salesforce.com employees who created accounts in third party services that got breached.
  6.  Would IDPs be able to subscribe to events for all email addresses, or just those proven to be “theirs”?
     *   IdPs can subscribe only their own domains. There is no legitimate reason for Yahoo.com to get the ‘credential compromise’ event for gmail.com domain.

I hope I was able to address your questions. Feel free to ask clarifying questions and thanks for the time stamp suggestion.

Stan

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Matt Domsch via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Date: Tuesday, March 16, 2021 at 1:05 PM
To: openid-specs-risc at lists.openid.net <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow
Stan, I have reservations about the practicality of use case A) – a credential is found on the dark web, I need to inform applications within the security mesh about this.  Perhaps your use case elaboration can clarify this for me.

In this scenario, a security service is doing scans of various sites, and (e.g. January 1, 2021) comes across a trove of compromised credentials – say usernames, email address, and plaintext passwords, and the site from which each was exfiltrated.  The service then publishes a “RISC - Credential Compromised” event to subscribers, including identity providers and applications that wish to be aware of such, for which an explicit trust relationship with the security service is established a priori.

Is the service de-duping scan results on its end?  There are tons of copies of these troves scattered around. If each time a new trove is found with the same (stale) info as before, it would (incorrectly) generate a new event for all other actors to deal with.

Would you emit the plaintext password in the event?  Without this (or including all possible salted hashed password values in the event for all hash algorithms, ugh!), a service has no way of knowing if the current password for this account matches, or if the user has rotated their password in the intervening time (perhaps years – I still get phishing attacks with a very old LinkedIn passwords from the 2012 exfiltration).  At the same time, emitting plaintext passwords is really poor form.

I presume the event would include an event_timestamp value (following the CAEP model) for when the service believed the credential was compromised, perhaps when the scan first found it, but not updated to now() every time a scan found it still present.  A receiver could then use this, assuming it also tracked timestamps of each credential change – not necessarily true – to ignore events that occurred earlier than the most recent credential change.

Without these protections, if it were to emit an event on every scan, “yes, this credential is still compromised”, receivers would see that the account, even if no longer compromised, and be expected to either de-dupe these themselves, or force the user through a painful reset process every few hours (scan timeframe).  That would feel like a denial-of-service attack.

If multiple security service companies are doing these scans, by definition separately, a subscriber to more than one service would get duplicated events, and would have to de-duplicate them themselves somehow.  I suppose that’s a point for vendor lock-in. 😊

Would applications be able to subscribe to events for all sites, or just those proven to be “theirs”?  For the password reuse concern, they may want to get them for “all sites”. But that is a huge privacy hole then – unrelated 3rd party sites would then be made aware that at least the user once had account on the other site.

Would IDPs be able to subscribe to events for all email addresses, or just those proven to be “theirs”?   For corporate-owned email addresses, this would seem to work – the IDP could then emit other events to revoke sessions and the like. For large consumer email address domains such as yahoo.com, gmail.com, outlook.com, this is again a huge privacy concern especially when a user will rarely be using SSO into downstream applications using these email addresses.  Similarly, not all corporate-owned applications have SSO enabled.  One can dream…

I’m hoping that you have protections outside the definition of the event that address these concerns, and likely many more I haven’t thought about. I’d love to hear about them.

Thanks,
Matt

Matt Domsch
VP, Engineering Fellow
matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>
mobile: 512-981-6486
www.sailpoint.com<http://www.sailpoint.com/>

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> on behalf of Stan Bounev via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Date: Tuesday, March 9, 2021 at 11:01 AM
To: Tim Cappalli <Tim.Cappalli at microsoft.com>, atultulshi at google.com <atultulshi at google.com>, openid-specs-risc at lists.openid.net <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] "Credential compromise" event discussion tomorrow
Annabelle, thanks for your input on ‘credential compromise’ during the meeting. I see your point about potential interoperability issue with the first use case below. For the people who were not able to join today, your argument was that some IdPs could be ‘trigger happy’ and send the ‘credential compromise’ event too often versus other IdPs that are conservative.

The receiving party will be the one to decide how to implement it. The vulnerability and other security systems allow to weigh/prioritize alerts. In the actual implementation, the receiving party can dial up or down the alerts from a given IdP based on the history with that IdP.

Additional point that Tim raised, is that the IdP is the authoritative party. When an IdP blocks, ask for a step-up authn or something else,  the receiving party does not question or ask for clarification.

In terms of interoperability, the ‘credential compromise’ seem to be similar to the ‘session revoked’ event. In the latter event, the session is revoked based on the heuristics of the ‘admin’ (as per the event description). Most common reasons for session revoked include compromised accounts, employee termination, and other insider threats. Those are not strictly defined in our spec and an ‘admin’ or IdP could terminate a session based on heuristics.

I see three paths forward:

  1.  Define the criteria for a credential to be compromised and for a session to be revoked.
  2.  Drop the two use cases #1 and #3 below and just keep use case #2.
  3.  Do nothing. Include the ‘credential-compromise’ as is and leave it the SE to determine how to treat the events by each IdP.

Let me know what you think.

Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210316/6427a757/attachment-0001.html>