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