<div dir="ltr">Thanks for sending this over! I had to miss the last meeting, but I have some thoughts about this one.<br><br>As Marius alluded to, I can see a few use cases where this would be applicable.<br><br>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 "<font face="monospace">credential_compromised</font>" reason?<br><br>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.<br><br>First, I don't think the CCDB should ever send a plaintext credential to the receiver. This, however, introduces a minor problem.<br><br>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.<br><br>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, <a href="http://example.com">example.com</a>, is compromised and this database becomes public. In this case, the CCDB would tell the RP for <a href="http://foo.com">foo.com</a> that the subject <a href="mailto:johndoe@example.com">johndoe@example.com</a> had a credential compromised in a breach since <a href="mailto:johndoe@example.com">johndoe@example.com</a> has an account on <a href="http://foo.com">foo.com</a>. However, there's no guarantee that the same credential was used, so sending the hash may reveal information that doesn't belong to <a href="http://foo.com">foo.com</a>.<br><br>To that end, I'd propose that the CCDB not send a credential to the receiver at all. Instead, the CCDB <i>could</i> 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).<br><br>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 <a href="https://www.usenix.org/system/files/sec19-thomas.pdf">some excellent work</a> in this space that I'm hoping gets adopted by other parties really soon (and I encourage y'all to check out!)<br><br>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.<br><br>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.<br><br>Thanks again for sending this over! Very exciting stuff.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 4, 2020 at 5:27 PM Stan Bounev via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net">openid-specs-risc@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-337406045336774907WordSection1">
<p class="MsoNormal">Hello everyone,<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p style="margin:0in 0in 0.0001pt">Feedback from Annabelle:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<u></u><span style="font-size:10pt;font-family:Symbol;color:black"><span>·<span style="font:7pt "Times New Roman"">
</span></span></span><u></u><span style="color:black">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<u></u><span style="font-size:10pt;font-family:Symbol;color:black"><span>·<span style="font:7pt "Times New Roman"">
</span></span></span><u></u><span style="color:black">Are you thinking at all about “batch” cases, e.g., a big password file gets dumped on pastebin?<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:27pt;vertical-align:middle">
<u></u><span style="font-size:10pt;font-family:Symbol"><span>·<span style="font:7pt "Times New Roman"">
</span></span></span><u></u>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.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><span style="font-family:-webkit-standard,serif;color:black">On Dec 20, 2019, at 8:13 PM, Marius Scurtescu via Openid-specs-risc <</span><span style="font-family:-webkit-standard,serif"><a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a><span style="color:black">>
wrote:</span><u></u><u></u></span></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">A new RISC event type came up while looking at clearing house use cases, see meeting notes for December 10.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> Event Type URI:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <a href="https://schemas.openid.net/secevent/risc/event-type/credential-compromised" target="_blank">https://schemas.openid.net/secevent/risc/event-type/credential-compromised</a><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> Credential Compromised signals that a given credential for the account identified<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> by the subject was compromised. If the exact same credential is used by the same<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> account then the Receiver should take action.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> Attributes:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - credential-type:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - password<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - PIN<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - ...<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - credential-hash<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - hash-method:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - SHA-256<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> - ...<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "iss": "<a href="https://idp.example.com/" target="_blank">https://idp.example.com/</a>",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "jti": "756E69717565206964656E746966696572",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "iat": 1508184845,<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "aud": "636C69656E745F6964",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "events": {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "<a href="https://schemas.openid.net/secevent/risc/event-type/credential-compromised" target="_blank">https://schemas.openid.net/secevent/risc/event-type/credential-compromised</a>": {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "subject": {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "subject_type": "iss-sub",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "iss": "<a href="https://idp.example.com/" target="_blank">https://idp.example.com/</a>",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "sub": "7375626A656374",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> },<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "credential-type": "password",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "credential-hash": "41ef4bb0b23661e66301aac36066912dac037827b4ae63a7b1165a5aa93ed4eb",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> "hash-method": "SHA-256",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> }<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> }<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> }<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">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:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><a href="https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases" target="_blank">https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases</a><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
</div>
</div>
_______________________________________________<br>
Openid-specs-risc mailing list<br>
<a href="mailto:Openid-specs-risc@lists.openid.net" target="_blank">Openid-specs-risc@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-risc" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-risc</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><table border="0" cellpadding="0" cellspacing="0" style="border-collapse:collapse;border-spacing:0px;max-width:100%;background-color:transparent;color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:12px"><tbody><tr><td width="50"><img src="https://duo.com/assets/img/email/duo-logo-email-signature.gif" width="50" height="50" style="border: 0px; vertical-align: middle; display: block;"></td><td width="10"><img src="https://duo.com/assets/img/email/spacer.gif" width="10" height="50" style="border: 0px; vertical-align: middle; display: block;"></td><td valign="middle"><div style="margin:0px;font-family:Helvetica,sans-serif;display:inline"><strong style="display:inline">Jordan Wright</strong> <div style="margin:0px;display:inline"><span style="color:rgb(153,153,153)">/</span> Principal <span>R&D Engineer</span></div> <div style="margin:0px;display:inline"><br><a href="mailto:jwright@duo.com" style="color:rgb(99,178,70);text-decoration:none" target="_blank">jwright@duo.com</a></div> <div style="margin:0px;display:inline"><br style="display:inline"><a href="https://duo.com/" style="color:rgb(99,178,70);text-decoration:none" target="_blank">Duo.com</a></div></div></td><td><img src="https://duo.com/assets/img/email/spacer.gif" width="1" height="50" style="border: 0px; vertical-align: middle; display: block;"></td></tr><tr><td colspan="4"><div style="margin:0px;display:inline"><br><span style="display:inline">----------<br>The Most Loved Company in Security</span></div></td></tr></tbody></table></div></div></div></div></div></div>