Loans Flash

29/x Metamask’s current solution is the (very effective) bright red warning (shown in the first image) telling the user how dangerous a signature may be when using ETH_SIGN. I think this is sufficient - although the best solution would be disabling the functionality entirely.

28/x Well- it turns out this is a Metamask issue, and many other platforms (such as Geth) do not allow ETH_SIGN to sign raw transactions anymore. Thus, much of the documentation online DOES NOT APPLY to Metamask currently. This leads to quite a bit of confusion on the risks here.

26/x Thus, there is (currently) no harm in signing messages when using PERSONAL_SIGN.

25/x So how does PERSONAL_SIGN protect against this? By using PERSONAL_SIGN, the prefix at the beginning of the message prevents it from being used as a transaction (as it would fail, since the prefix is not valid instructions for the evm).

24/x The attacker can then broadcast that transaction to the network, posing as you, and the transaction will be executed. All by signing a message in Metamask.

23/x But - how can an attacker tell the network to execute that transaction? Because, with ETH_SIGN, you signed the raw transaction (in the form of a message) with your private key.

17/x eth-sig-util is simply a group of signing functions - which is exactly what we are looking for. Within here, we should find personalSign.

16/x Looking around a bit - we can see that personalSign comes from the “eth-sig-util” package. By checking out the code there - we can see the real PERSONAL_SIGN logic.

15/x Looking at PERSONAL_SIGN, we can see the rabbit hole goes a bit deeper. Instead of simply signing the raw message data and returning it - a new “personalSign” function is being called with our message.

14/x Finally - after that scavenger hunt - we can see the real logic of ETH_SIGN. And it’s….simple. The raw message is signed with the private key, and that is all. Why is this dangerous? How is this different from PERSONAL_SIGN?