Dartroom/contracts

Server signed transactions

Closed this issue · 0 comments

The current Dartroom systems rely on the submit verification (the method of submitting a transaction to verify the user is the owner of the address), but this is not protected from spoofing. An attacker could change out the blob of the object for another one of their liking and trick us into submitting the transaction. This will not directly affect the on-chain status, but it can make them pass the check in our API and manipulate the database state.

This problem stems mainly from the txID field is not secured, which represents the hash of the transaction values. If we add a signature to the object which is singed with a secret on the server and includes the txID in it's hash, we can verify the signature when the object is returned after signing. We can then decode the blob and check the secret validity against the txID from the blob the verify the correct transaction was send. If the txID is not the same it gets catches by the sig verification and if the blob has been modified to the same txID the Algorand node will report it as a invalid transaction.

const txn = {
	description: "Opt-into USDCa.",
	blob: "",
	txID: "BHGYUJ6URPNUXIKKWCCF4GSDHOLEZENF5DL3MZUXF3OGX45GWZBA",
	signers: [
		"E3GZF5GUOQDW52TZ4X3PU5YR34447BOTVL6X3OOW3CB5EPHWIEISXK5BCI"
	],
	dependsOn: null,
	sSignature: ""
}

We probably want to make this optional, to prevent client side limitations. In that case we expect the user will not care, since it will never update database information in that case. (or at least we are not the leak in that case)

The sSignature can be used to authenticate that the returned transaction originated from your server. If the transaction was manipulated or provided by another server the system will return an authentication error.

Tasks:

  • add sSignature field to return transactions format
  • add createSignature function
  • add verifySignature function