Enable raw payloads to be signed in extension #1358
Conversation
…pes and use u8aToU8a for raw data before signing
There was a problem hiding this comment.
What prevents from letting users sign a TX without showing them they are signing a TX?
What prevents you from wrapping your payload with <bytes></bytes> which is easy enough ?
This is a security measure that should not be removed. Also it's been there for long enough that changing this behavior would actually break Dapps :)
|
@Tbaut thanks for such a quick response!!! What prevents them from letting users sign a TX without showing them they are signing a TX?I suggest a change in the UI that warns clearly and directly to users that they're about to perform a low-level operation with an unknown consequence, something: "STOP THERE: You are about to sign an unknown transaction. Make sure you trust the source, as it could potentially drain all your funds."
What prevents you from wrapping your payload with which is easy enough ?Given I'm crafting a raw substrate transaction with a custom tool called https://github.com/virto-network/virto-sdk/tree/main/sube and using a cross-platform signing library called lib wallet (https://github.com/virto-network/virto-sdk/tree/main/libwallet) which one of the backends we're developing is Polkadot js, we need to sign raw payloads in order to complete the operation and avoid the BadProof error when submiting. |
|
The security issue is about having a malicious Dapp. Having a warning on the Dapp doesn't make sense, if it's malicious there'll obviously be no warning. To sign in to some websites, e.g Polkassembly, they let users sign a non legible random number. This is bad practice and they should let them sign some text containing a random number, but that's what they do. Say Polkassembly is hacked tomorrow and instead of a random number, it's a substrate TX that transfers all the user funds to the attacker. Well users will blind sign, because the extension won't try to decode the TX since it's a raw signing. It is absolutely essential to differenciate raw signing from transaction signing. Regarding your use case, I don't get why you need raw signing. Why don't you let users sign the TX as a TX? |
this PR closes #1357 by adding a type 'raw' signature that enables developers to sign raw payloads using the 'signRaw' method in the extension and avoid forced data manipulation in the signing process.