[Openid-specs-risc] RISC Compromise Credential event

[Jason Garbis]

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/20220714/df0c64b7/attachment.html>