"Secret link" is an oxymoronical concept. Resource identifiers are exactly that: identifiers. They're not private names, and any design that relies on keeping them secret is inherently flawed. If it's accessible on the openly resolvable web, then the content needs to be treated as if it's public. If your use calls for authentication or authorization, then actually use an authentication or authorization system.
They are in fact private names, because they're unknown to the public. This is in fact an authentication system.
Yes, the public could guess a 128-bit random value and log in - but that's no different from the ability of the public to guess your password, or your session cookie, or your SSL session state, or whatever. Every authentication mechanism is based on "There is a high-entropy value, and nobody but the authorized user has it." It makes no difference from a theoretical standpoint - i.e., in terms of whether it's "actually" an authentication system" - whether the high-entropy value is sent to the server as part of the URL or via a header or via POST data.
(It clearly makes a difference from a practical standpoint, because in order to have a secret link, the link must actually be kept secret. But that's no different from, like, the need to not expose your cookies to third-party requests or whatever.)
I understand they are known to the public? Every MTA from any random site between the sender and receiver gets the mail, including secrets. They can all decide to scan the site, write them in a log,...
Then, when you click the link, if you don't have https, anything between receiver and site also gets a copy of the link. And there are proxys, add injecting ISPs, etc.
Are you claiming that the contents of emails are public?
Which "random sites" see emails between sender and receiver?
Yes, proxies and ad-injecting ISPs can see the contents of plaintext HTTP. But that's hardly a reason to say that logging into a website with a password or presenting a cookie doesn't count as an authentication system!
I've always treated the contents of emails as public. Things are getting a little better these days, but email is still often forwarded in plaintext through multiple servers owned by disparate parties. There is no reason to believe anything you send in an email will remain private.
I agree no one is saying that. I think they are being unsound in refusing to say that but also saying that URLs don't count as an authentication system.
Is the argument "Information in an email should be treated as public"? Then how do you validate users on signup in the first place? How do you ensure that someone owns an email address that they claim to own?
Is the argument "Information sent over HTTPS should be treated as public"? Then why does the argument not apply to passwords or cookies?
They're saying that URLs aren't an authentication (or authorization) system.
I'm curious to know how those advocating a position similar to this think something like a password reset facility on a website should work. We all know security-sensitive systems should rely on alternative methods of authentication anyway, but for those of us living in the real world where billions of people access millions of systems via websites using their email address as ID/fallback, what else would you do that does not rely on trusting emails to be acceptably secret for at least a few minutes?
You seem to have difficulty following the logical throughline here. There is no playing dumb in the previous comment.
Let's put it in a statement instead of the form of a question: it does not follow to respond to the quoted part ("URLs aren't an authentication (or authorization) system") with remarks about "those of us living in the real world where billions of people access millions of systems via websites using their email address as ID/fallback[...]".
You (both of you) are confusing the subject here: URLs vs reaching back to drag emails and their privacy into focus. They're different fucking things! Stop responding to comments about one with responses that deal in the other!
Billions of people access websites using their email addresses? Granted! Now say something about URLs if that's what your quibble is and shut up about the emails that the URLs were sent in and whether or not those emails are private. The comments about email are misdirection at worst, and a sign of unclear thinking (and a hazard to confuse others) at best.
You're doing some subtle jiu jitsu and extracting a lot of benefit from responding to the previous message as if it said "if the names are not known to the public, then[...]". It does not.
Resource identifiers, on the web[1], are not private names—not even by virtue of the fact they were communicated over a private channel—and they need to be treated as public, full stop. URLs are not private names, simply because of what they are.
> It makes no difference from a theoretical standpoint [...] whether the high-entropy value is sent to the server as part of the URL or via a header or via POST data.
It makes no difference from an information theoretic standpoint. There is no reason, however, to narrowly consider the information content and its entropy and declare that you are done. From an information architecture standpoint, there is a difference.
> But that's no different from, like, the need to not expose your cookies
It is different, for the reasons above.
(Every entropy-based cryptographic protocol also begins with observations how hard it is to do something in practice, and is then founded on exploiting those side effects. To describe a system and then wave away concerns that it is merely unfit "from a practical standpoint" makes it a failure of a design. It is fundamentally at odds with not just the evaluation criteria that protocols fit for use are measured against, but from which they are born.)
I'm not following your argument. What is this thing that URLs are which makes them public?
For instance, I could argue "Fingerprints are not passwords, and they need to be treated as public, because of what they are" - because I can finish that sentence with "and what they are is a pattern that's left on every single random thing you touch, and is also immutable and impossible to rotate."
It's almost certainly true that you do, you're just being dishonest. (The alternative is worse.)
> What is this thing that URLs are which makes them public?
You mean other than being identifiers (universal identifiers, at that)? It's like you've never used or encountered someone else articulating an argument that incorporates (or would be appropriate to incorporate) the phrase "by definition" before.
If your security protocols are compromised by the card catalog or the Rolodex being invented—compromised not by knowing the contents of a given resource, but by knowing the correct way to refer to or otherwise describe the identity of that resource—then you don't really have very good security in your protocols (particularly in a world where those things have already been invented).
> What's the analogous thing for URLs?
What? What a bizarre request.
The next time someone asks you to make your case in terms of bad analogies just because they can't get away from using them themselves, you can go ahead and say, "No, thanks. I'll pass."
I understand full well that you are claiming that URLs are public by definition. I am disputing that you are interpreting the definition correctly.
The invention of the card catalog and the Rolodex does not compromise anything, because the card catalog and the Rolodex simply catalogue information that is public, but in a poorly-accessible format. No card catalog can find the name of an unpublished, self-printed book that is sitting in my house. No Rolodex can determine the extension of the direct line at my work. Since I am claiming the URL in question is not public in the first place, I am claiming that it would not end up catalogued.
Can you explain, clearly, how this URL would end up catalogued? "By definition" is not an argument.
You're mixing up "public" with "published" (intentionally, perhaps).
> I am disputing that you are interpreting the definition correctly.
And I question whether you've actually made an attempt to grok the subject as a matter of definition, rather than substituting your synthesis (based on an experiential mental model of the subject derived from firsthand inference) in place of what URLs actually are actually supposed to be. (Meaning the playing dumb comment would be apropos here as well.)
> Can you explain, clearly, how this URL would end up catalogued?
The mechanics of how don't have to be explained, because that's how definitions work (whether you accept it or not). Explaining how is not a pre-requisite to what.
But if you're really dying for some missing insight, how about pausing to demonstrate some awareness of the catalyst of this tedious exchange: that a company that was founded on the basis related to cataloguing documents and their public identifiers is (shocker) doing that, right before doing things to/with them—and this has led to people who built up a model of the world similar to yours getting upset because the mistaken assumptions that went into building that model conflict with they're now being told is happening.
"Secret link" is an oxymoronical concept. Resource identifiers are exactly that: identifiers. They're not private names, and any design that relies on keeping them secret is inherently flawed. If it's accessible on the openly resolvable web, then the content needs to be treated as if it's public. If your use calls for authentication or authorization, then actually use an authentication or authorization system.