Open natevw opened 1 year ago
I'm waiting for more discussion/agreement here but if we proceed in this direction we should also open over at https://github.com/web3-storage/w3ui/issues a corresponding ticket to track the work that would be needed on the client side. But I think the improvements here could be started independently from the client side — splitting the approval link into the GET landing page vs. actual PUT/POST handler and making sure the approval request itself is tied to some sort of temporary nonce or server secret–derived that prevents forgery of the approval itself.
Thanks for the great write up & careful analysis @natevw 👍
I agree that we need to close the loop here, which probably means adding a tiny bit of user friction. Personally I think it's probably fine to require entering an OTP-style code into the client - that feels like the simplest thing, and it doesn't feel surprising as a user since it's pretty similar to 2FA flows that people have probably seen before.
@natevw I think the proposed solution is a good and sufficient first step to fix this. Are you interested in working on it? I'd like it to be resolved ASAP. Thanks for raising and thanks especially for proposing a solution.
@alanshaw Yeah, I think this would be a great scope for me to tackle. I'll start proceeding as above but to re-iterate I'm thinking roughly:
@natevw thank you for the feedback and proposal.
I wrote some notes about this here https://purrfect-tracker-45c.notion.site/Email-auth-flow-d33f0715024a47c18a8114ba284e9c07.
I not 100% sure that adding a new step to do a POST is the way to go here but there's definitely improvements to be done.
@hugomrdias re. your:
I not 100% sure that adding a new step to do a POST is the way to go here but there's definitely improvements to be done.
This is what you captured as "Avoid SafeLinks and other auto open email client stuff" in the notes, and is ultimately just an HTTP standards issue.
Any GET
handling is expected to be:
essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
And:
The purpose of distinguishing between safe [i.e. like GET] and unsafe [like PUT/POST] methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
And since afaict it doesn't require any changes but to the access-api
server itself splitting the process into:
GET
)POST
) to actually approveis to me the "low hanging fruit" here and I'm hoping to submit a PR for it asap.
The thing here is that clicking on the email link does not change any state, it works just like any other GET just return whats there already in this case the ucan delegation. Either using websockets or the http response that also includes the delegation as string and QRcode.
This is mostly covered by #348 (→ #398) and the "validation phrase" part of #347 (→ #399). The UI side has a placeholder issue https://github.com/web3-storage/w3ui/issues/307 as well.
The
access-api
package's/validate-email
endpoint does not provide sufficient authentication or authorization for its anticipated purpose.Currently the flow works roughly as follows:
The problem
The flow as implemented is not secure/trustworthy. There are two significant flaws, closely related but kept separate to highlight the need for improvements on both sides:
GET
request — this breaks HTTP expectations generally and will be particularly problematic if the user has any sort of link preview enabled or if the email goes through a provider that itself scans links (e.g. the MS Outlook Safelink protection service). This is the "authentication" side: just because a URL was fetched does not mean that the intended recipient was the one that actually fetched it.In most cases where email login is used, whoever opens the link gains access to the underlying session/identity. But in this case opening the link gives someone else that access! A malicious actor Eve simply provides Alice/Bob's email address — now Eve just needs to wait for Alice's computer to generate a page preview for the link, or for Bob to click the link, to gain access to their account.
[Currently this is not a big deal because there's not really much of any "account" to access, and things like upload lists and such are siloed per-identity rather than per-email. But the anticipated purpose is to link actions done by that identity to the email, otherwise the apps wouldn't be attempting to validate email at all!]
Proposed solution
This came out of a discussion we had at https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1673387411040389 around these concerns (which were also brought up in https://github.com/web3-storage/specs/issues/26 earlier as well). There needs to be some way to "close the loop" and ensure that maliciously requested privileges associated with an email address aren't accidentally approved.
I would propose the following improved email validation flow:
PUT
/POST
request to the API, which can then broadcast the delegated token thing to the original requestor. [Note that this is actually the link/request data that can't be predictable by anyone without the original link; i.e. need to ensure that an attacker can't just skip straight to this step and approve the association without actually proving they have access to the claimed email address]This approval form both resolves the HTTP/"Safelinks" problem and provides the authenticated end-user a way to review the request more thoroughly before approving. It does not necessarily require any changes to the client library(ies) to just solve the
GET
vs.PUT
/POST
problem. But to really solve the authorization side the client library will need to be updated to show something that the user matches up with a copy on the approval form. It could actually be a combo of:Alternatives considered
The workflow above isn't 100% foolproof! A user could still somehow/someway plow through and approve something they shouldn't have if they were tricked or in a hurry or whatnot. Some potentially more robust solutions might be:
There might be some sort of crypto-ey out-of-the-box-thinking de-centralized solution lurking here too, but we might prefer loading the problem more on the business side to keep the UX simpler!