Ensure that attacker can not use malicios email to user as an attack vector

[Gozala]

This came up in https://github.com/web3-storage/w3protocol/pull/318. I have not put whole lot of thought into this, but we need to make sure that attacker can't gain access to user account via phishing user into clicking a link they've send them to their email address.

In other words there must be:

1. Some way for the user to assess who are they authorizing (e.g. if they got 10 concurrent authorization emails how do they know which one to authorize and which one to reject) ?
2. Authorization requests should expire in reasonable time frame to limit the window for the attack.
3. Perhaps emailed link should always take you to the keyring or some intermediary so that authorization scope could be adjusted as needed

[natevw]

Agree with this, I think there are some potential holes here as well. I posted some initial thoughts at https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1673387411040389 but will right them up as a second pass here. I've at least confirmed that with the new access API (testing via https://github.com/web3-storage/w3ui/tree/46f731ce72ce52cf3210716d1a6845654f2c5819/examples/react/uploads-list) that I can:

1. Load the demo in one browsing context and fill in any email address
2. Open the ensuing link in a different browsing context to get "Email Validated"
3. The original browsing context now considers itself authenticated

This implies to me that I could put your email address in, wait for you to click the link (which you might do on accident thinking it was your own request, or out of curiosity because it's unclear what it's even about, or maybe even could happen automatically by way of an email client link preview or Safe Links style scanning service e.g./cf. ??)

— regardless, now the principal identity I generated is active, but in a way the system attributes to you.

Right now each identity the client generates seems in practice to be isolated from the others, but as I understand it in the future they will. At that point then via the flow above I could:

• steal against your quota to upload large files of my own
• login as you and see your own account details/uploads
• any other potential abuse of the centralized aspects of that email-linked identity

…which seems problematic!

[natevw]

I'm still getting up to speed on the current implementation and in-the-works plans for all this, but as I mentioned in Slack there's probably a need to "close the loop" somehow.

Maybe there's a cryptographic tooling in all the DID/UCAN stuff that magically sidesteps this? But without pondering that angle too much, my gut feel is that this does just need to be a more burdensome process for the end user:

• a browser dance that only works if the email link is opened in the same browser as the corresponding auth request — limits my usage if I'm using different devices for different things :-/
• an extra step that tries to scare the user into being careful before really approving the validation — troublesome from a human behavior perspective!
• a full on crypto flow involving the QR code (but again troublesome for usage between some devices)
• ~a PIN~ OTP/nonce digits in the email that the user has to copy over into the UI client to complete the flow — drawbacks?

[natevw]

There may be more here in general, but I've written up the specific vulnerabilities I see with a concrete proposal over at https://github.com/web3-storage/w3protocol/issues/333 which is where any implementation would need to start (as well as improvements to w3ui components).