[Openid-specs-risc] "Compromised credential" event - background information

Mon Feb 10 02:35:52 UTC 2020

Thanks for sending this over! I had to miss the last meeting, but I have
some thoughts about this one.

As Marius alluded to, I can see a few use cases where this would be
applicable.

The first is when the IDP discovers a compromised credential for an RP. In
this case, I think it should just reset the credential and send an "Account
Credential Change Required" event. As an aside, looking through the event
types, I noticed there wasn't a "reason" field for this. Perhaps there
might be a case for having a "credential_compromised" reason?

The second use case is when a Compromised Credential Data Broker (CCDB)
discovers a compromised credential for an IDP or RP. This case is trickier.

First, I don't think the CCDB should ever send a plaintext credential to
the receiver. This, however, introduces a minor problem.

Let's say the CCDB sends the SHA256 hash to the receiver. The problem is
that the receiver can't do much with this immediately, since they almost
certainly (or should!) only have a hashed credential on their end. So
they'd have to cache the received hash, wait for the user to login, then
check if the provided password matches the SHA256 hash.

While we have a bit of prior art with the OAuth event types that suggests
we can send over a hashed credential, I don't think that quite applies
here. A common scenario is that some third-party website, example.com, is
compromised and this database becomes public. In this case, the CCDB would
tell the RP for foo.com that the subject johndoe at example.com had a
credential compromised in a breach since johndoe at example.com has an account
on foo.com. However, there's no guarantee that the same credential was
used, so sending the hash may reveal information that doesn't belong to
foo.com.

To that end, I'd propose that the CCDB not send a credential to the
receiver at all. Instead, the CCDB *could* send some kind of metadata about
the credential, such as if it was a "third party" breach, or if there was
information to suggest the credential was 100% tied to the RP (e.g.
recovered from password-stealing malware).

When the IDP/RP receives this event, they would know to then check-in with
the CCDB when the user logs in to do some kind of privacy-preserving
exchange to determine if this particular credential were the one
compromised. Google has been doing some excellent work
<https://www.usenix.org/system/files/sec19-thomas.pdf> in this space that
I'm hoping gets adopted by other parties really soon (and I encourage y'all
to check out!)

If in this scenario it was the IDP that received the event and they
verified the credential was indeed compromised, they could then send an
"Account Credential Change Required" downstream.

This flow places the burden of verification on the CCDB and receiver, but
doesn't seem to be any less actionable than sharing the hash directly along
with the potential upside of allowing a privacy-preserving verification.

Thanks again for sending this over! Very exciting stuff.

On Tue, Feb 4, 2020 at 5:27 PM Stan Bounev via Openid-specs-risc <
openid-specs-risc at lists.openid.net> wrote:

> Hello everyone,
>
>
>
> I want to share with you the background information we had so far about
> this event. See attached a high-level use case. Below I’ve added some
> points Annabelle raised below in the past, plus a sample event code Marius
> suggested.
>
>
>
> Feedback from Annabelle:
>
>
>
> ·         A hash of a partial password is not really useful on its own.
> There are ways to make it useful, but a lot of them are likely to decrease
> overall security of the recipient system in non-obvious ways. The safer
> ways to use this information aren’t obvious and are harder to implement. We
> need to be careful that we do not inadvertently promote anti-patterns. I’m
> not saying we that can’t define this event, we have to be careful about it,
> and make sure we provide the right guidance.
>
> ·         Are you thinking at all about “batch” cases, e.g., a big
> password file gets dumped on pastebin?
>
> ·         We need to be very careful if we’re going to include
> credentials or artifacts derived from credentials in events. A plain hash
> of the password is vulnerable to rainbow tables and cracking rigs. A hash
> of a PIN is especially vulnerable, given the reduced search space.
>
>
>
>
>
>
>
> On Dec 20, 2019, at 8:13 PM, Marius Scurtescu via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
>
>
> A new RISC event type came up while looking at clearing house use cases,
> see meeting notes for December 10.
>
>    Event Type URI:
>
>
> https://schemas.openid.net/secevent/risc/event-type/credential-compromised
>
>
>
>    Credential Compromised signals that a given credential for the account
> identified
>
>    by the subject was compromised. If the exact same credential is used by
> the same
>
>    account then the Receiver should take action.
>
>
>
>    Attributes:
>
>      - credential-type:
>
>        - password
>
>        - PIN
>
>        - ...
>
>      - credential-hash
>
>      - hash-method:
>
>        - SHA-256
>
>        - ...
>
>
>
>    {
>
>      "iss": "https://idp.example.com/",
>
>      "jti": "756E69717565206964656E746966696572",
>
>      "iat": 1508184845,
>
>      "aud": "636C69656E745F6964",
>
>      "events": {
>
>        "
> https://schemas.openid.net/secevent/risc/event-type/credential-compromised":
> {
>
>          "subject": {
>
>            "subject_type": "iss-sub",
>
>            "iss": "https://idp.example.com/",
>
>            "sub": "7375626A656374",
>
>          },
>
>          "credential-type": "password",
>
>          "credential-hash":
> "41ef4bb0b23661e66301aac36066912dac037827b4ae63a7b1165a5aa93ed4eb",
>
>          "hash-method": "SHA-256",
>
>        }
>
>      }
>
>    }
>
>
>
>
>
> Keep in mind that an event like this is useful not only for a clearing
> house use case but for all implicit and pseudo implicit use cases, see
> sections 3.3, 3.4 and 3.5:
>
> https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>

-- 
*Jordan Wright*
/ Principal R&D Engineer

jwright at duo.com

Duo.com <https://duo.com/>

----------
The Most Loved Company in Security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20200209/1a67ebdb/attachment.html>