Re:Bots, so many bots
by akoboldfrying on Thursday October 03, 2024 @03:14AM
(#41728043)
Ah, you're right. The receipt is "spendable" by the acceptor, since it contains nothing identifying the original spender.
One approach might be for the Site to expose a public key (like SSH, completely independent of TLS/hosting) which the User carries over to create the Burn Trigger.
The Attestor which generate a random secret associated with Burn Trigger record, and encrypt it with the public key to create a challenge.
To burn the token, the Site would need recover the random secret with its private key and supply it. That would also replace the need for a confirmation code in idempotence.
A malicious site would not be able to secretly spend unless it also stole the private key of the place it wanted to spend it at.
It can because nothing in that artifact binds it to the one and only one site that the user expects. The only thing keeping it from being used elsewhere is if everybody keeps it secret, and the malicious not-really-spending site simply won't obey that rule.
In scenario form:
1. User goes to Attestor, inputs a Token for an output of a Burn Trigger. (I object to "receipt" because that suggests a finalized transaction, and nothing has really happened yet.)
2. Users submits that Burn Trigger to malicious AcmeWidgetForum, which (fraudulently) reports a successful burning and puts a "Verified" badge on the account.
3. In the background, AcmeWidgetForum acts like a different User and submits the Burn Trigger to InnocentSite, which sees no issue and burns it to create a new "verified" account.
Even if the User can somehow audit "which site actually claimed responsibility for burning my Token" and sees that "InnocentSite" shows up instead, most won't check, and even knowing that AcmeWidgetForum was evil won't do much to stop the site from harvesting more unwitting Users.