Improvements regarding signed URLs

[m-mohr]

Solves issue #379

[soxofaan]

I would add a recommendation that the expiry time should be order of minutes/hours "to give clients enough time to download all assets, while still mitigating the security risk.

[m-mohr]

Hmm... I'm not sure how high the security risk is actually. Google uses signed URLs for Docs, Spreadsheets etc. and they seem to not expire at all.

[soxofaan]

a difference is that the google doc user can stop sharing a doc (invalidate the signed url)

[m-mohr]

Yes, that is what issue #341 has been opened for.

[soxofaan]

After pondering some more on this, some thoughts:

• shouldn't we be more enforcing about the expiration time for security reasons (e.g. at least explicitly RECOMMEND it)? The current statement "Back-ends are responsible ..." is weaker than a recommendation I think.
• Would it make sense to let the user choose whether they want public signed URLs that can expire or URLs protected with bearer token auth (that can not expire)? The expiry problem is mitigated by the renewal mechanism, but security minded users might want to avoid publicly available URLs that they can not invalidate themself.

I know, the tin foil hat factor of these points is quite high, and it's probably not urgent to tackle these the moment, but it might become a problem in the future.

[m-mohr]

• shouldn't we be more enforcing about the expiration time for security reasons (e.g. at least explicitly RECOMMEND it)? The current statement "Back-ends are responsible ..." is weaker than a recommendation I think.

As also stated above, I'm not sure how high the security risk is actually, so I'm not sure this is actually required.

• Would it make sense to let the user choose whether they want public signed URLs that can expire or URLs protected with bearer token auth (that can not expire)?

I assume that could make sense, but that would need to be tracked in a new issue for 2.0 (breaking for clients).

The expiry problem is mitigated by the renewal mechanism

The wording we add here doesn't necessarily mean that previous signed URLs get invalid, it just means expired links will be renewed. Revoking signed URLs is a different issue: #341 We may decide that re-requesting this endpoint also invalidates previously generated signed URLs, but currently that's not the intention yet.

[soxofaan]

I didn't know about #341 , that should indeed tackle most of the concerns raised here.

[m-mohr]

@soxofaan It seems this is important for you? I can certainly move the milestone up for #341 and make a proposal for API 1.1 in the next days.

[soxofaan]

Well, to give some background: the current implementation that @laxiwuka is working on for the VITO backend does not allow invalidation (there is no storage, just an added hash in the URL based on a secret to check that the URL hasn't been tampered with).
The only tool to improve security is using shorter expiration times (changing the secret would invalidate all URLs for all users).

#341 requires more work (because of persistent storage involved) than other alternatives (that do not require persistent storage or state) I am exploring here:

• push the spec to make expiration times as short as possible
• make it possible to opt-in for bearer-token based urls
• allow user or client to set expiration time in some way

[m-mohr]

Thanks for the details, @soxofaan. It sounds like this is not your long-term solution though so I'll merge this and have opened PR #381 with a proposal to revoke signed URLs.

[soxofaan]

Yes, good to merge this already.
Another follow up about toggling between signed urls and bearer token download urls: #382