5 ms·

I agree. It would have been interesting to do something like secret-token:example.com/abcdef with the option of secret-token:example.com/auth/abcdef (where auth

I agree. It would have been interesting to do something like secret-token:example.com/abcdef with the option of secret-token:example.com/auth/abcdef (where auth is an arbitrary token type picked by example.com)

marcosdumay 6y ago
Well, you can create your tokens with the structure "domain/authtype/code". I think that's a good idea, and is plainly allowed by the standard. Yeah, it would be better if it was standardized too, but I didn't think about all the corner cases. Maybe it can't be standardized.
- jlokier 6y ago
  > I think that's a good idea, and is plainly allowed by the standard. Watch out, "secret-token:domain/authtype/code" is not a valid secret-token by the standard! The standard has grammar: [RFC8959] secret-token-URI = secret-token-scheme ":" token secret-token-scheme = "secret-token" token = 1*pchar [RFC3986] pchar = unreserved / pct-encoded / sub-delims / ":" / "@" pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" That means "/" cannot be part of a secret-token, and a strictly standard-compliant scanner will not pattern-match on "secret-token:domain/authtype/code". I think that may be a design mistake as people will inevitably build tokens with those characters (using the same reasoning you did), and they won't show up in some scanners (any that are strictly compliant). "/" is allowed in query strings despite being a path delimiter before the query string; allowing it in secret-token would make sense too. Fortunately it's not a security problem as long as "/"-delimited paths in tokens don't start with "/", because the preceding characters will be enough to match anyway. However, if you have a scanner where you whitelist some strings after being shown matches, the fact it doesn't match the security part of the token introduces a risk of mistakenly whitelisting too broadly (just the domain in this example), and of course there's a chance someone may use a path starting with "/" without realising this is a problem.
  - marcosdumay 6y ago
    Ouch. I didn't check the grammar on the other RFC this one pointed. I just assumed it was sane (even more because the inline text explaining it makes no mention of the slash). I really didn't expect somebody to define a URL as having a single URL part. Now my opinion is that this RFC is ill conceived.
  - sp332 6y ago
    You could add a bunch of %2F to stand in for slashes, but that's pretty clunky.
Forge36 6y ago
Is it? Spec https://www.rfc-editor.org/rfc/rfc3986.txt https://www.rfc-editor.org/rfc/rfc3986.txt 2.2 states "/" is reserved and should be encoded vs "-" which is unreserved. Thinking further: I don't want a secret to identify what it's for. That increases odds it's used when leaked accidentally.

marcosdumay 6y ago

Well, you can create your tokens with the structure "domain/authtype/code". I think that's a good idea, and is plainly allowed by the standard. Yeah, it would be better if it was standardized too, but I didn't think about all the corner cases. Maybe it can't be standardized.

jlokier 6y ago
> I think that's a good idea, and is plainly allowed by the standard. Watch out, "secret-token:domain/authtype/code" is not a valid secret-token by the standard! The standard has grammar: [RFC8959] secret-token-URI = secret-token-scheme ":" token secret-token-scheme = "secret-token" token = 1*pchar [RFC3986] pchar = unreserved / pct-encoded / sub-delims / ":" / "@" pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" That means "/" cannot be part of a secret-token, and a strictly standard-compliant scanner will not pattern-match on "secret-token:domain/authtype/code". I think that may be a design mistake as people will inevitably build tokens with those characters (using the same reasoning you did), and they won't show up in some scanners (any that are strictly compliant). "/" is allowed in query strings despite being a path delimiter before the query string; allowing it in secret-token would make sense too. Fortunately it's not a security problem as long as "/"-delimited paths in tokens don't start with "/", because the preceding characters will be enough to match anyway. However, if you have a scanner where you whitelist some strings after being shown matches, the fact it doesn't match the security part of the token introduces a risk of mistakenly whitelisting too broadly (just the domain in this example), and of course there's a chance someone may use a path starting with "/" without realising this is a problem.
- marcosdumay 6y ago
  Ouch. I didn't check the grammar on the other RFC this one pointed. I just assumed it was sane (even more because the inline text explaining it makes no mention of the slash). I really didn't expect somebody to define a URL as having a single URL part. Now my opinion is that this RFC is ill conceived.
- sp332 6y ago
  You could add a bunch of %2F to stand in for slashes, but that's pretty clunky.

Forge36 6y ago

Is it? Spec https://www.rfc-editor.org/rfc/rfc3986.txt https://www.rfc-editor.org/rfc/rfc3986.txt 2.2 states "/" is reserved and should be encoded vs "-" which is unreserved. Thinking further: I don't want a secret to identify what it's for. That increases odds it's used when leaked accidentally.