<div dir="ltr">





<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Thanks Atul - here’s a recap, and an idea for discussion around the the RISC Credential Compromise event</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Atul’s notes:</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>Proposal</i></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>We should include a “password verifier” field in the Compromise Credential event.</i></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>The verifier should contain the digest of the password</i></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>A separate field should contain an indicator of the algorithm used to compute the digest</i></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>Issues</i></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>How can the Transmitter and Receiver agree on the algorithm?</i></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue""><i>Is it feasible to send the verifier without knowing the “salt” value</i></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Use Case: A service provider discovers an alleged credential (username/password combination) in an untrustworthy location (e.g.<span class="gmail-Apple-converted-space">  </span>a Dark Web repository).<span class="gmail-Apple-converted-space">  </span>This credential is for a specific identity and may be claimed to be for a specific service - let’s say it’s for <a href="mailto:DarthVader@Comcast.net"><span class="gmail-s1" style="color:rgb(220,161,13)">DarthVader@Comcast.net</span></a> 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.<span class="gmail-Apple-converted-space"> </span></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">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.<span class="gmail-Apple-converted-space"> </span></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">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.</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">Approach: The transmitter should be able to obfuscate the password in a receiver-specific way, so that only the intended receiver can access it.<span class="gmail-Apple-converted-space"> </span></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">First idea:<span class="gmail-Apple-converted-space">  </span>Assumption: Receiver only stores the hashed password value. Could the transmitter hash the password, and only send the hashed value to the receiver?</p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">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</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">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.</p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p2" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">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?</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 12, 2022 at 7:19 PM Atul Tulshibagwale 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 dir="ltr">Hi all,<br><div>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: <a href="https://hackmd.io/eDzKdeVITr22DNcw7FRt1Q?view" target="_blank">https://hackmd.io/eDzKdeVITr22DNcw7FRt1Q?view</a></div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Atul</div><div><br></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="https://lists.openid.net/mailman/listinfo/openid-specs-risc" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-risc</a><br>
</blockquote></div>