Discord said this discussion is too long to fit a chat message and I think it should be discussed in a thread so here it is. @jot2re said:
The reason this is an issue is that there is nothing build-in to useDevconTicket that ensure that it has been constructed freshly for its current use and thus it can be replayed. I am aware that we want to prevent this through what org.tokenscript.auth verifies, but this does not prevent copying the useDevconTicket since the proof of knowledge within the useDevconTicket can be reused since there is no linking to the current usage. My suggestion is simply to allow the challenge without the Proof of Knowledge to take an auxiliary argument that can be used to link it to its specific usage. This auxiliary info can then be stored as part of useDevconTicket and can either be the identity of a smart contract or a website domain concatenated with a timestamp or some other challenge.
Hi @jot2re#9588 I thought we have given up making sure useDevconTicket is fresh because the person who wish to authenticate against a website can always get a copy from a smart contract call which the ticket holder made in the past. As of your suggestion, I'm confused as to what it means.
My guess is you mean this:
π) to allow the-challenge-without-the-Proof-of-Knowledge to take an auxiliary argument that can be used to link it to its specific usage.
That is, the challenge is issued without the consideration of the PoK, for example, the challenge is the hash of Ethereum Signed Message:\34hotel-bogota.com-challenge80918203810293810
π) to allow the response to the challenge not to contain the PoK.
Which one is what you are after?
If π: I have considered π in the past TS design sessions, the reason is to prevent man-in-the-middle attackβ‘ and we previously (I believe) discussed methods such as using a derived key (derivated by the website's domain name) or ask proof of knowledge of the private key should user wallet support such use (or both). We can implement such a challenge prefix (website domain), be aware that against our wish, we reduced Authenticator to a utility that provides the useDevconTicket for either using in a transaction or web authentication, leaving Webster (i.e. web developer) to decide how to form JWT and parse it from their server end, so the said change would be purely in the Webster's space and not affecting @olehhrib's library.
β‘ The website instead of sending genuine challenge, forwards challenges from a malicious source. this allows the man-in-the-middle to authenticate against a website that the ticket holder doesn't intend to use, by setting up a website and phishing the user into authenticating against it.