6 ms·

> to open one secret link "Secret link" is an oxymoronical concept. Resource identifiers are exactly that: identifiers. They're not private names, and any de

> to open one secret link "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.

geofft 5y ago
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.)
- hyperman1 5y ago
  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.
  - geofft 5y ago
    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!
    - c22 5y ago
      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.
    - pwdisswordfish0 5y ago
      > 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! That's fine. No one is saying that. They're saying that URLs aren't an authentication (or authorization) system.
      - Silhouette 5y ago
        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?
        pwdisswordfish0 5y ago
        What relation does your question have to the statement you're quoting?
        geofft 5y ago
        As a wise person once said, playing dumb isn't clever, it's just obnoxious.
        pwdisswordfish0 5y ago
- pwdisswordfish0 5y ago
  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.)
  - geofft 5y ago
    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." What's the analogous thing for URLs?
    - pwdisswordfish0 5y ago
      > I'm not following your argument. 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."

geofft 5y ago

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.)

hyperman1 5y ago
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.
- geofft 5y ago
  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!
  - c22 5y ago
    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.
  - pwdisswordfish0 5y ago
    > 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! That's fine. No one is saying that. They're saying that URLs aren't an authentication (or authorization) system.
    - Silhouette 5y ago
      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?
      - pwdisswordfish0 5y ago
        What relation does your question have to the statement you're quoting?
        geofft 5y ago
        As a wise person once said, playing dumb isn't clever, it's just obnoxious.
        pwdisswordfish0 5y ago
pwdisswordfish0 5y ago
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.)
- geofft 5y ago
  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." What's the analogous thing for URLs?
  - pwdisswordfish0 5y ago
    > I'm not following your argument. 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."