[Openid-specs-risc] RISC Compromise Credential event

Mon Jul 18 23:24:31 UTC 2022

Thanks Jason and Martin for your thoughts and suggestions.

There's also a related concern from the eKYC working group (+Mark Haine
<mark at considrd.consulting>) of not including sensitive information in CAEP
events, and instead have the Receiver "check back" with the Transmitter.

I think the discussion we should really have is about how we can handle
sensitive information in SSE events. Here are some choices:

   1. Do we provide for a mechanism by which a Transmitter marks an event
   as having sensitive data, so that the Receiver can proactively obfuscate /
   prevent logging or other copying of such data
   2. Do we specify that SSE events cannot contain sensitive information
   (e.g. PII or compromised password text) and require the Receiver to do work
   to fetch this information in a more secure way?
   3. Do we specify that SSE events may always contain sensitive
   information, and the Receiver needs to ensure that information it receives
   from a Transmitter is handled with the same sensitivity and data protection
   policies that they apply to PII or other sensitive data?

Atul

On Mon, Jul 18, 2022 at 2: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/20220718/18408472/attachment-0001.html>