Potential vulnerability with web3.personal.sign as authentication mechanism

Problem:
Suppose mysensitiveinfo.com uses `web3.personal.sign` for authentication.
malicious.com is another website that lures users into authenticating. When a user asks for a challenge message for her to sign for address A, malicious.com's server requests a similar challenge for A from mysensitiveinfo.com . malicious.com then relays the challenge to the user, gets the message signed and can now log into mysensitiveinfo.com .

Possible mitigation:
Have MetaMask emulate the same-origin policy by requiring messages that are to be signed to be prefixed with the page's domain name + some delimiter.

Start by tracing the MetaMask handling of web3.personal.sign and the authentication flow described in the issue. Review the proposed page-domain prefix mitigation, including its effects on signed messages and existing dapps; done requires a decided, compatible approach that prevents cross-site challenge replay.

Written by the indexing model from the issue text.