Display 8/8 address chars during signing instead of 4/4

[stoooops]

Overview

Patch UI to display 8 leading and 8 trailing characters for transaction request instead of 4 and 4.

Motivation

This fixes security issues around address collisions which match first/last 4 characters. 8 digits is not enough and can be bruteforced locally.

For the forseeable future, 16 characters of collision protection should be reasonable. Extrapolating from 2019 data provided by (@)banteg:

New Look

Old Look

Security Incident

https://twitter.com/Alexintosh/status/1540047636467748870

Author

Patched written by cory.eth (Cory Gabrielsen) (@cory_eth).

[banteg]

6 leading and 6 trailing maybe?

profanity can go through 179 mh/s according to a 2019 benchmark, it would take it

• 24 seconds to find matching 8 chars
• 1.7 hours for 10 chars
• 18.2 days for 12 chars

a generative image alongside would also make it harder to spoof, since it depends on all the bits of the address

[uneventfulhorizon]

It's a rushed/lazy attacker that can't set aside 18 days to generate the appropriate vanity address?

[aviggiano]

I think the root cause problem is not knowing if you're interacting with a verified (by who) contract or not.

Maybe integrating with the etherscan API, getting that information and displaying it in the UI?

[outdoteth]

It's easy for an attacker to verify the contract on etherscan too, and gives a false sense of security if there is a "verified" or green check mark in the UI imo. Although having the information that a contract verified is still useful.

[aviggiano]

I agree.
Maybe rephrasing my point with your remarks:

The root cause is not knowing if you're interacting with a verified smart contract recognized by the team.
When alexintosh.eth says "the correct one is..." he means "the contract Convex deployed and publicly acknowledged is"

So maybe a robust solution would involve having a repository of "approved" smart contracts + a verification checkmark.

[mholtzman]

@stoooops thanks for the submission. the code you changed displays the recipient address after the transaction has been broadcast so not as sensitive, but I updated the PR with the 6 character standard in both places Frame prompts for user confirmation of a transaction before signing (normal transaction signing and approve ERC-20 token spend). we'll get this merged and released ASAP

[stoooops]

Great, I actually was just looking at this again. Was just working on getting it to build w/ my changes so I could take some screenshots.

I was thinking about whether 8/8 is better than 6/6 but I wanted to see it visually.

[stoooops]

Here is the visualization with 6...6 vs 8...8. I think there is still plenty of whitespace and it looks fine with 8/8, and clearly the security is 4 chars (2 bytes) stronger.

I've added a further change to increase it to 8/8 which I think would be my vote.

You can change it back to 6/6 if you prefer as well.

[stoooops]

Extrapolating @banteg's data (based on 178,205,000 keys/sec collision attack) to 16 characters suggests a collision time of 3,261 years.

If we assume the attacker can do ~6x faster at 1,000,000,000 keys/sec, then it would still take 584 years.

(Google Sheet: link)

For the forseeable future (3-5 years), it would take an attacker a considerable amount of compute ($$$) to generate a full 16-character collision. Every reduction in collision is a better chance a user spots the delta and we save someone from losing their funds.

I think for this UX use case, 8/8 is subjectively nice looking while still being strong security for the forseeable future.

[mholtzman]

keep in mind that in all these cases, users can always view the full addresses both in Frame and on their devices if they're using one. I think 8/8 is good to settle on.