Project

One World
NFTDeFi
15,000 USDC
View results
Submission Details
Severity: low
Invalid

Hashing the Name and Version in EIP-712 Downgrades the User Experience and users of the protocol are vulnerable to phishing attacks.

Summary

In the EIP712Base.sol contract, the _setDomainSeparator function hashes the name and version parameters using keccak256. This approach is contrary to the intent of EIP-712, which aims to provide human-readable transaction details for users. Hashing these values diminishes the user experience by obfuscating essential information that should be displayed clearly.

Vulnerability Details

The problematic code in the _setDomainSeparator function is as follows:

function _setDomainSeparator(string memory name, string memory version) internal {
// @info: Encoding with incorrect type
// Name and version should not be hashed
domainSeparator = keccak256(
abi.encode(
EIP712_DOMAIN_TYPEHASH,
keccak256(bytes(name)), // Hashing the name
keccak256(bytes(version)),// Hashing the version
address(this),
bytes32(getChainId())
)
);
}

In this implementation, the name and version fields are hashed using keccak256, which goes against the spirit of EIP-712, where these values are expected to be presented in plain text to the user for easy recognition and verification.

EIP-712 Context:

EIP-712 is designed to standardize how structured data is signed and verified off-chain and then transmitted to smart contracts. One of the key aspects of EIP-712 is that it allows for human-readable messages to be presented to users when signing transactions. The EIP specifies that fields like name and version (among others) should be kept in plain text to ensure that users can easily read and verify them before signing, improving the overall user experience and security.

Impact

  • Poor User Experience: By hashing the name and version, users will be presented with cryptographic hashes instead of human-readable text when reviewing the transaction. This makes it difficult for users to verify important details about the transaction, reducing trust and usability.

  • Misrepresentation of Data: The purpose of EIP-712 is to provide users with clear and understandable transaction details. Hashing these fields defeats this purpose and introduces confusion, as users may not be able to match the transaction with the correct dApp or version easily.

  • Security Risk: If users cannot verify the name and version of the contract interacting with them, they might be more prone to phishing attacks or inadvertently signing malicious transactions. Clear and verifiable details help users assess whether the transaction is legitimate.

Tools Used

Manual Code Review

Recommendations

To improve the user experience and align with the intent of EIP-712, it is recommended to encode the name and version as plain strings in the _setDomainSeparator function, without hashing them. This ensures that the transaction details remain human-readable, allowing users to easily verify the data before signing.

By encoding the name and version as plain strings, the contract will display user-friendly information, enhancing both usability and security.

Updates

Lead Judging Commences

0xbrivan2 Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Design choice

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!