3 ms·

That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. And sometimes it isn't

by thayne 3y ago

That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. And sometimes it isn't practical to require a POST request or a cookie. And the risk of a url leaking can be greatly mitigated if the url is only valid for a short period of time.

ta1243 3y ago
> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. Technically you're right -- after all sending an authentication as a separate header doesn't make any difference. GET /endpoint/?Auth=token or GET /endpoint Auth: token Sends the same data over the wire. However software treats URLs differently to headers. They sit in browser histories, server logs, get parsed by MITM firewalls, mined by browser extensions, etc using https://user:pass@site.com/endpoint https://user:pass@site.com/endpoint or https://auth:token@site.com/endpoint https://auth:token@site.com/endpoint Would be better than https://site.com/endpoint/user/pass https://site.com/endpoint/user/pass or https://site.com/endpoint/?auth=token https://site.com/endpoint/?auth=token As the former is less likely to be stored, either on the client or on the server. I don't do front end (or backend authentication -- I just rely on x509 client certs or oidc and the web server passes the validated username)
- paulgb 3y ago
  For better or worse, basic auth in the URL isn't really an option any more, (e.g. see https://stackoverflow.com/a/57193064 https://stackoverflow.com/a/57193064). I think the issue was that it reveals the secret to anyone who can see the URL bar, but the alternative we got still has that problem and also has the problem that the secret is no longer separable from the resource identifier.
  - thayne 3y ago
    The browser could hide the secret after it is entered.
    - paulgb 3y ago
      Yeah, and it would still be useful for queries that never appear in the URL bar (like EventSource and WebSocket, where setting an Authorization header is not something that’s exposed by the browser)

by thayne 3y ago

ta1243 3y ago

> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. Technically you're right -- after all sending an authentication as a separate header doesn't make any difference. GET /endpoint/?Auth=token or GET /endpoint Auth: token Sends the same data over the wire. However software treats URLs differently to headers. They sit in browser histories, server logs, get parsed by MITM firewalls, mined by browser extensions, etc using https://user:pass@site.com/endpoint https://user:pass@site.com/endpoint or https://auth:token@site.com/endpoint https://auth:token@site.com/endpoint Would be better than https://site.com/endpoint/user/pass https://site.com/endpoint/user/pass or https://site.com/endpoint/?auth=token https://site.com/endpoint/?auth=token As the former is less likely to be stored, either on the client or on the server. I don't do front end (or backend authentication -- I just rely on x509 client certs or oidc and the web server passes the validated username)

paulgb 3y ago
For better or worse, basic auth in the URL isn't really an option any more, (e.g. see https://stackoverflow.com/a/57193064 https://stackoverflow.com/a/57193064). I think the issue was that it reveals the secret to anyone who can see the URL bar, but the alternative we got still has that problem and also has the problem that the secret is no longer separable from the resource identifier.
- thayne 3y ago
  The browser could hide the secret after it is entered.
  - paulgb 3y ago
    Yeah, and it would still be useful for queries that never appear in the URL bar (like EventSource and WebSocket, where setting an Authorization header is not something that’s exposed by the browser)