Tradeogre Grin withdrawal flow and authenticator

When withdrawing cryptocurrencies from Tradeoge, such as BTC with non-interactive transactions, the user enters an amount and an address.
In the next step, Tradeoge ask for the authenticator token (if user has activated authenticator). After entering the right token, the transaction is immediately performed.

When withdrawing Grin with interactive transactions, the user is asked to enter an amount and then Tradeogre asks for the authenticator token.
After entering the right token, Tradeogre displays the slatepack message.
After signing the message, the user pastes the response message and clicks the “Finalize” button. The transaction then gets immediately finalized.

I would suggest that exchanges instead ask for the authenticator token after clicking “Finalize”, in order to make it harder to inject an unwanted response on behalf of the user. Also, the finalization step has a higher impact than the creation of the initial slatepack message.

Consider following scenario:
A user initiates a transaction on an exchange. While the user is busy with signing the message in the wallet, a malicious browser extension could use that time for sending an unwanted response to the exchange. The transaction then would immediately be finalized by the exchange and the coins would go to the attacker. If the gap were closed, an unwanted response could still be injected invisibly, but there would be at least a chance for the user to prevent that.

If the malicous extension can sign valid responses, then you’re screwed and order of steps doesn’t matter.

How would they prevent that?

The question is is this realistically possible. Slatepacks are when innitialising a transaction sending to a specifc public key as far as I understand.
“A SlatepackAddress is a bech32 encoded ed25519 public key and when shared with other parties is used to represent the ability to receive Grin transactions.”

So it is not like slatepacks can be intercepted and the public-key of the receiver can be changed by a malicous party. Which means a malicous party could only sign if they know your privatekey, which they do not.
For more information on slatepacks and slatepack adresses:

I was thinking that the extension would sign a response with its own key, instead of the user’s key, while the user could sign the message offline.

For example by constructing a request manually (not necessarily in the browser) that sends the response, the authenticator token and probably a session token and blocking the original request. Not sure how exactly, but I think there would be more room than if the response without authenticator token is possible,

TO creates a slatepack message without knowing the user’s public key, so as I understand, the response can be signed with any key.

As long as you enter an address, this address is based on your public-key. Meaning it cannot be changed. But lets say someone has access to your browser and changes the slatepack address when requesting the transaction, yes in that case you would have a problem. So from that perspective, entering the security token at least after the innitiation of the transaction, would be more secure

But TO has no option to enter an address for slatepack withdrawal.

Ok, in that case I agree it would be better to enter the security token in the last step. Still to have access to a private encrypted browser session would be very difficult, so in reality it is only a minor security risk which is present for all other crypto currencies as well. Still good catch, by asking for the security token later on, or asking to enter again a security token, it would be more secure. Problem is that security tokens are valid for some time, so if you would login and enter the security token, the token would be the same 1 minute later when the security token would be requested for the second time :thinking: In any case, I do not think TO would change their workflow only for Grin, since this security risk is present for all crypto withdrawals.

For the test exchange @vegycslol wants to build, it could possible be addresses since it only focusses on Grin withdrawels:

The flow for Grin is already different from the flows for non-interactive transactions, so maybe they would reconsider that if they see a good reason. They could for example make sure that a token is only used once.

A, I suddenly realise this is already the case if you use Google Authenticator. So maybe requesting two tokens in a short time frame is not a problem at al.