[Openid-specs-risc] "Compromised credential" event - background information
Jordan Wright
jwright at duosecurity.com
Wed Feb 12 16:49:33 UTC 2020
Hey Stan,
Just to make sure, we’re not proposing that the privacy-preserving exchange be standardized as part of RISC, right?
I’d err on deferring altogether and not prescribing any kind of particular verification exchange as part of the event type profile. That way the sender and receiver can determine which works best for their use case and risk/privacy appetite.
On a side note, though, I do expect to see some kind of formalization to happen regarding the privacy-preserving verification introduced by Google. I also failed to mention previously that one of the protocols proposed by Google was independently proposed by researchers at Cornell and Cloudflare [0]. Hopefully they could work together to get an official spec together! I think it’d be a valuable use of time, personally.
[0] https://rist.tech.cornell.edu/papers/c3.pdf
> On Feb 11, 2020, at 1:02 PM, Stan Bounev <stanb at vericlouds.com> wrote:
>
>
> Jordan, I like your suggestions, specifically about not sending the credential, but metadata and then having a separate, privacy-preserving exchange. The only downside I see of this approach is the second exchange, which will need to be standardized.
>
> I’m currently working on an updated version of the use case.
>
> Question to the group: What do you think about having a second exchange using a privacy-preserving method? If you’re okay with that, I can amend the use case in a way to factor it.
>
> Stan
>
> From: Jordan Wright <jwright at duo.com>
> Date: Sunday, February 9, 2020 at 6:36 PM
> To: Stan <stanb at vericlouds.com>
> Cc: Openid-specs-risc <openid-specs-risc at lists.openid.net>
> Subject: Re: [Openid-specs-risc] "Compromised credential" event - background information
>
> 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 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
>
>
> ----------
> The Most Loved Company in Security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20200212/b71a0899/attachment-0001.html>
More information about the Openid-specs-risc
mailing list