Encourage use of different cryptographic secrets for each network

[benjamincburns]

Givens/Assumptions

• Standard security best practice is to use cryptographic secrets (i.e. cryptographic seeds, seed phrases, and private keys) in such a way as to compartmentalize the risk and impact of their exposure, which in turn allows for the strictness, strength, and cost of the security of these secrets to be tuned based on what information they're meant to protect.
• Compartmentalization of secrets by network is a natural approach to achieve the above which would serve most use use cases well.
  • If anything here needs verification, it's this.
• Cryptographic secrets used as "dummy secrets" in certain environments (e.g. development and automated test environments) are very cumbersome to keep secure¹.

Current behavior

Today my only option for network-level compartmentalization is to save my secrets (seed phrases) somewhere outside of MetaMask (I'd recommend 1Password if you're using a digital medium), and then lock/restore from seed phrase every time I want to switch networks.

Enforcing this requires a high level of personal discipline, and even in when such discipline is exercised, accidentally using an account meant for one network on another network is still easier done than avoided.

Desired behavior

Seed phrases, private keys, and any other secrets should be associated with a particular network, and the UI should discourage reuse between private/trusted and public/untrusted networks by making doing so somewhat burdensome.

Proposed changes

What follows is an example of how I think this could be achieved, but my purpose in writing it is to illustrate the goal behind this change more so than to perfectly specify these changes. As such, please don't implement this as written without further consideration.

• [ ] On vault creation, when not restoring from seed phrases MetaMask should generate different mnemonics for each network.
• [ ] Accounts added via private key are associated with a specific network and not immediately reusable on multiple networks.
• [ ] When adding custom networks, users are asked whether the network is a trusted (dev/test/local nets) or untrusted² (testnets, some multi-party private nets, mainnet) environment.
• [ ] When adding custom networks, users are given an option to restore from a seed phrase, or given a newly generated seed phrase if they do not elect this option.
• [ ] When restoring a network with a given seed phrase, or when adding an account to a network via a private key, if the network is indicated to be an untrusted network and if the user is using the same seed phrase/private key as was used in any of their other untrusted networks, a very noticeable but simply worded (language barriers) warning message should pop up telling the user that they should avoid reusing mnemonics between untrusted environments to compartmentalize their losses. This should purposefully be a somewhat jarring experience.
• [ ] Similar to the previous case, in the event that the seed phrase is reused from a trusted environment, the user should be required to type something like "I understand that my ETH might be stolen if I continue" before they can proceed. This should purposefully be an even more jarring experience.

_{1. Though ideally these are still randomized to prevent this sort of thing. ↩ 2. The "trusted"/"untrusted" language was the best generic terminology I could come up with on short notice, and I'm not at all wedded to it. I just didn't quite like "Production/Test" or "Production/Development" because some testnets are public and therefore untrusted. ↩}

[danfinlay]

One issue I'd like to see this account for is post-plasma. When a user sends some ether into a plasma shard, will they be forced to use a different account within the shard? If so, that should be actively discussed w/ plasma people.

[benjamincburns]

When a user sends some ether into a plasma shard, will they be forced to use a different account within the shard?

@danfinlay we can talk face-to-face on this, but I'm not familiar with plasma. However, In terms of security, I'd regard a sharded network as one environment, so using different secrets per shard would be overkill. However, I thought one of the key requirements of sharded networks was account affinity to a particular shard. If that assumption holds in plasma (assuming it was ever correct at all), then I'd think that MetaMask would need to handle the account->shard mapping, anyway.

Either way, I'd think that while we should make sure that a solution to this issue doesn't preclude a solution to plasma sharding, I'd hope that addressing sharding shouldn't block this issue.

[danfinlay]

This may be a good idea, but it will take a while before it can get to production since it touches pretty much every part of our architecture, from UI, down to undefined behavior for existing users who may need a migration path, so there would be a lot of work involved in moving to this.