[Openid-specs-risc] RISC Compromise Credential event

Thu Jul 21 20:56:50 UTC 2022

Thanks Martin and Atul - There are definitely multiple layers here, which
we need to explore.

Commenting on Martin’s first reply in which he makes the good point that
the compromised credential can be of many different types (e.g. password,
bearer token, Certificate, FIDO security key, etc), and the credential may
be in one of many different forms (plaintext, hashed, potentially
encrypted, etc).  The implication of this is that - regardless of whether
this information is intended to be transmitted as part of a CAEP event or
via a proprietary API, there still needs to be an agreed-upon taxonomy with
which to communicate the format of the data being sent, if we intend for an
automated system to be able to reliably act upon the result.

Tom/Stan from VeriClouds - How does your system handle this classification?
(I do not remember, and I sadly didn’t take detailed notes about this from
the March 22 meeting). e.g. is there normalization (or an assumption
thereof) by the transmitter in terms of the credential format?

Let’s take a step back - is our use case / intention that the Receiver be
able to act on this Credential Compromised event in an automated way? Or to
initiate a manual validation process? There are risks on both sides, both
from false negatives and from malicious positives (e.g.  “denial of
service”). If the our goal is more to enable a manual validation process -
this presumes a lower volume of events - then including the credential in
an extended CAEP message could be useful, as long as there is a
privacy-preserving mechanism of some sort. This could also avoid the
problem of having to define a taxonomy for how the credentials are
formatted, since the human reviewer will be presumably able to determine
this. Alternatively, we could simply follow the current model and rely on a
non-standard additional mechanism for the Receiver to obtain the
credentials.

Aiming for an automated process is more challenging, especially since it
feels like it’ll be more brittle, and rely on correct classification of the
credential in order to avoid false negatives by the Receiver. It feels like
the damage from a false negative (where there actually is a compromise of a
valid credential, but the system mistakenly rejects it) is worse than a
false positive (the claimed credential is invalid, but the system indicates
it’s compromised anyway) for a Credential Compromised event.

(I will reply to Atul’s email in a separate thread in order to keep them
separate and focused)

Regards

Jason

On Mon, Jul 18, 2022 at 5:07 PM Martin Gallo <mgallo at secureauth.com> wrote:

> Hey all,
>
> Just wanted to provide some feedback, at least from my perspective, as
> this topic was discussed when we introduced the Compromise Credential
> event, but not sure if ended correctly capture in the notes.
>
>
>
>
>
> I think the “credential compromise” event is one of great value for
> Identity Providers and other services alike, but as mentioned it has some
> challenges. In particular, you want to signal that something happened (the
> compromise) to a particular subject, without revealing the credential
> itself. For some of the credential types, this is not a problem (e.g. a
> FIDO2 security key can be referenced by it’s public identifier, an X.509
> certificate by its serial number or fingerprint) but the problem is with
> bearer tokens and memorized secrets.
>
>
>
> Main challenges IMHO are:
>
> - Compromised credentials can be found in different formats, and the
> transmitter of the event not always might have it in a reversible format.
> For example, a data breach might contain users password hashes extracted
> from a compromised database (sometimes salted, sometimes not), while
> another data breach might directly contain the users’ password in plain
> text. There might be even cases where the same data breach contains
> credentials that are store in different formats or using different
> algorithms.
>
> - There receiver might not have the credential stored at all, or have it
> in a format that is not reversible and different from the one that the
> transmitter have.
>
> - Identifying the exact credential (e.g. username and password
> combination) in the event is not possible without leaking information about
> the credential itself.
>
>
>
>
>
> This is a known challenge and has been explored by both the academia as
> well as the industry, which has several security vendors providing these
> services with privacy-preserving protocols and mechanisms. A good paper
> that I like to use as reference is “Protocols for Checking Compromised
> Credentials” by Lucy Li et.al. [1], in which the protocol and threat
> model for checking compromised credentials is formalized.
>
>
>
>
>
> Going to Jason’s point and the actual proposal, I think that having a
> standardized method to check compromised credentials that works in an
> interoperable way and covers the different scenarios in a
> privacy-preserving way is going to be very challenging. My suggestion is
> that, unless we want to enter into the burden of supporting a secure and
> privacy-preserving mechanism to actually identify the exact credential
> (which might be a little bit out of scope), we do keep the current
> specification of the event with the semantic of signaling that “a
> credential related to the subject identifier was compromised”. The
> validation of the credential can be provided by the transmitter as a
> separate or related service, but using a check protocol that provides the
> aforementioned guarantees. BTW, VeriClouds demo’ed their implementation
> (with two separate API calls) at the March 22nd SSE WG meeting [2].
>
>
>
> Bests,
>
> Martin.
>
>
>
> [1] https://dl.acm.org/doi/10.1145/3319535.3354229
>
> [2] https://hackmd.io/@oidf-wg-sse/wg-meeting-2022_03_22#VeriClouds-demo
>
>
>
> *From:* Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> *On
> Behalf Of *Jason Garbis via Openid-specs-risc
> *Sent:* Thursday, July 14, 2022 4:33 PM
> *To:* Atul Tulshibagwale <atul at sgnl.ai>
> *Cc:* openid-specs-risc at lists.openid.net
> *Subject:* Re: [Openid-specs-risc] RISC Compromise Credential event
>
>
>
> Thanks Atul - here’s a recap, and an idea for discussion around the the
> RISC Credential Compromise event
>
>
>
>
>
> Atul’s notes:
>
>
>
> *Proposal*
>
> *We should include a “password verifier” field in the Compromise
> Credential event.*
>
> *The verifier should contain the digest of the password*
>
> *A separate field should contain an indicator of the algorithm used to
> compute the digest*
>
> *Issues*
>
> *How can the Transmitter and Receiver agree on the algorithm?*
>
> *Is it feasible to send the verifier without knowing the “salt” value*
>
>
>
>
>
> Use Case: A service provider discovers an alleged credential
> (username/password combination) in an untrustworthy location (e.g.  a
> Dark Web repository).  This credential is for a specific identity and may
> be claimed to be for a specific service - let’s say it’s for
> DarthVader at Comcast.net and the alleged password is “Th3DarkS1deR0cks”. In
> this example, our user Darth likely uses his Comcast email as the
> identifier for many online services (bank, health club, etc), so this
> credential is actually for an unknown site or sites. (The compromise may or
> may not identify the service for which this credential is supposedly valid
> e.e. EmpireBank). If Darth has poor password security practices, he may in
> fact reuse this password across multiple sites.
>
>
>
> The service provider here wants to emit an event that this credential has
> been compromised, but wants to to avoid transmitting this password as
> cleartext.
>
>
>
> Problem: How can the transmitter securely convey the password to the
> receiver for validation and necessary action? It feels wrong to rely on
> only transport security to encrypt the password, since it’s entirely likely
> that the event will be logged or examined during its transmission.
>
>
>
> Approach: The transmitter should be able to obfuscate the password in a
> receiver-specific way, so that only the intended receiver can access it.
>
>
>
> First idea:  Assumption: Receiver only stores the hashed password value.
> Could the transmitter hash the password, and only send the hashed value to
> the receiver?
>
> Issue: This would require that the the receiver inform the transmitter of
> its hashing algorithm and salt mechanism, which is not information that
> should be shared
>
>
>
> Second Idea: The receiver provides a public key to the transmitter as part
> of a (to-be-specified) registration or stream setup process. The
> transmitter then uses this key to encrypt the password within the event.
> Only the intended receiver has the corresponding private key, so the
> password is obfuscated in transit.  The receiver can then decrypt the
> password, and then hash it (as needed) to compare it to its stored value,
> without having to share anything about its hashing mechanism.
>
>
>
>
>
> Thoughts? How much of a can of worms does this open up, in terms of now
> needing to specify a stream creation and registration protocol? Or, would
> it be sufficient for us to recommend that the credential SHOULD be
> obfuscated, and that the mechanism for that is (for now) out of scope for
> the spec?
>
>
>
> On Tue, Jul 12, 2022 at 7:19 PM Atul Tulshibagwale via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
> Hi all,
>
> A couple of weeks ago, I had agreed to write up the issue regarding the
> compromise credential event in RISC. Here's the little note:
> https://hackmd.io/eDzKdeVITr22DNcw7FRt1Q?view
>
>
>
> I think Jason Garbis has some interesting suggestions on how we can solve
> the issue that hashing the password requires the salt value, which is not
> with the Transmitter in this case. Jason, would you care to comment?
>
>
>
> Thanks,
>
> Atul
>
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20220721/1ef28aa9/attachment-0001.html>