5 ms·

We already have a solution to this. It’s called not including authentication information within URLs Even if search engines knew to include it, would every ins

We already have a solution to this. It’s called not including authentication information within URLs Even if search engines knew to include it, would every insecure place a user put a link know it? Bad actors with their own indexes certainly wouldn’t care

layer8 3y ago
How do you implement password-reset links otherwise? I mean, those should be short-lived, but still.
- 1231232131231 3y ago
  A short-lived link that's locked down to their user agent/IP would work as well.
- andersa 3y ago
  You could send the user a code that they must copy paste onto the page rather than sending them a link.
  - vmfunction 3y ago
    Hopefully using POST not GET. The GET links get logged in the HTTP server most of time. Just another great way to store your 'security credential' in plain text. Logs gets zipped and archive. Good luck with any security measure.
    - andersa 3y ago
      I mean of course the idea was to put it in a form that is sent using POST, but even then, it's a single-use reset code so once it shows in the log it's worthless.
      - fullspectrumdev 3y ago
        This makes a large assumption about application logic that is often incorrect. t. security auditor/researcher.
        rapind 3y ago
        It certainly does. Security usually comes at the cost of convenience and can incur confusion. In this example, where best practice may be to use one time tokens, you will end up with users who click on the secure link again (from their email) in the future to access the secure site and they’ll be frustrated when they have to go through the secure link generation dance again. Of course you can mitigate this with sessions / cookies, but that is also a security compromise and not device portable. It’s easy to say that these are minor uxp concerns, but enforcing a high level of security may have a significant user cost depending on your demographic. I have a demographic that skews older and non technical and they are pretty loud when they complain about this stuff… meanwhile they are also more likely to reuse passwords and forward emails with secure links in them!
        conductr 3y ago
        Some people will always find something to complain about. I feel like it’s completely reasonable to give a “sorry this link was only valid for 5 minutes and is now expired, request a new code here” message. State it in the email that originally contained the link and state it again on the page when they click it afterwards. This is incredibly common practice and very unlikely to be the first time someone has seen this workflow. If they want to complain further, direct them to a password manager and remind them there’s probably one built into their browser already
        rapind 3y ago
        > State it in the email that originally contained the link and state it again on the page when they click it afterwards. No one reads this stuff. I’m not saying this to be argumentative. I have a large user base and I know from experience.
- hnlmorg 3y ago
  As you said, short lived codes. And the codes don’t contain any PII. So even if the link does get indexed, it’s meaningless and useless.
dmurray 3y ago
Also, it would allow bad actors to just opt out of malware scans - the main vector whereby these insecure URLs were leaked.
- fullspectrumdev 3y ago
  So there was an interesting vector a while back where some email firewalls would reliably click on any link sent to them that was abused by spammers. Spammers would sign up for services that required a click on a link using blabla@domainusingsuchservice The services bots to check phishing would reliably click on the link, rendering the account creation valid. One particularly exploitable vendor for getting such links clicked was one that shares the name with a predatory fish that also has a song about it :)
  - rkagerer 3y ago
    SharkGate? Why coy about naming them?
    - reaperman 3y ago
      Barracuda. And for plausible deniability so they don’t have as much of a chance of catching a libel suit. Not sure how necessary or effective that is, but I do understand the motivation.
tsimionescu 3y ago
Actually, there are cases where this is more or less unavoidable. For example, if you want a web socket server that is accessible from a browser, you need authentication, and can't rely on cookies, the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).
- zer00eyz 3y ago
  Authentication: Identify yourself Authorization: Can you use this service. Access Control/Tokenization: How long can this service be used for. I swipe my badge on the card reader. The lock unlocks. Should we leave a handy door stopper or 2x4 there, so you can just leave it propped open? Or should we have tokens that expire in a reasonable time frame.. say a block of ice (in our door metaphor) so it disappears at some point in future? Nonce tokens have been a well understood pattern for a long time... Its not that these things are unavoidable its that security isnt first principal, or easy to embed due to issues of design.
  - bigiain 3y ago
    > Or should we have tokens that expire in a reasonable time frame. And that are single-use. (Your password reset "magic link" should expire quickly, but needs a long enough window to allow for slow mail transport. But once it's used the first time, it should be revoked so it cannot be used again even inside that timeout window.)
- skissane 3y ago
  > the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket). Put a timestamp in the token and sign it with a private key, so that the token expires after a defined time period. If the URL is only valid for the next five minutes, the odds that the URL will leak and be exploited in that five minute window is very low

layer8 3y ago

How do you implement password-reset links otherwise? I mean, those should be short-lived, but still.

1231232131231 3y ago
A short-lived link that's locked down to their user agent/IP would work as well.
andersa 3y ago
You could send the user a code that they must copy paste onto the page rather than sending them a link.
- vmfunction 3y ago
  Hopefully using POST not GET. The GET links get logged in the HTTP server most of time. Just another great way to store your 'security credential' in plain text. Logs gets zipped and archive. Good luck with any security measure.
  - andersa 3y ago
    I mean of course the idea was to put it in a form that is sent using POST, but even then, it's a single-use reset code so once it shows in the log it's worthless.
    - fullspectrumdev 3y ago
      This makes a large assumption about application logic that is often incorrect. t. security auditor/researcher.
      - rapind 3y ago
        It certainly does. Security usually comes at the cost of convenience and can incur confusion. In this example, where best practice may be to use one time tokens, you will end up with users who click on the secure link again (from their email) in the future to access the secure site and they’ll be frustrated when they have to go through the secure link generation dance again. Of course you can mitigate this with sessions / cookies, but that is also a security compromise and not device portable. It’s easy to say that these are minor uxp concerns, but enforcing a high level of security may have a significant user cost depending on your demographic. I have a demographic that skews older and non technical and they are pretty loud when they complain about this stuff… meanwhile they are also more likely to reuse passwords and forward emails with secure links in them!
        conductr 3y ago
        Some people will always find something to complain about. I feel like it’s completely reasonable to give a “sorry this link was only valid for 5 minutes and is now expired, request a new code here” message. State it in the email that originally contained the link and state it again on the page when they click it afterwards. This is incredibly common practice and very unlikely to be the first time someone has seen this workflow. If they want to complain further, direct them to a password manager and remind them there’s probably one built into their browser already
        rapind 3y ago
        > State it in the email that originally contained the link and state it again on the page when they click it afterwards. No one reads this stuff. I’m not saying this to be argumentative. I have a large user base and I know from experience.
hnlmorg 3y ago
As you said, short lived codes. And the codes don’t contain any PII. So even if the link does get indexed, it’s meaningless and useless.

dmurray 3y ago

Also, it would allow bad actors to just opt out of malware scans - the main vector whereby these insecure URLs were leaked.

fullspectrumdev 3y ago
So there was an interesting vector a while back where some email firewalls would reliably click on any link sent to them that was abused by spammers. Spammers would sign up for services that required a click on a link using blabla@domainusingsuchservice The services bots to check phishing would reliably click on the link, rendering the account creation valid. One particularly exploitable vendor for getting such links clicked was one that shares the name with a predatory fish that also has a song about it :)
- rkagerer 3y ago
  SharkGate? Why coy about naming them?
  - reaperman 3y ago
    Barracuda. And for plausible deniability so they don’t have as much of a chance of catching a libel suit. Not sure how necessary or effective that is, but I do understand the motivation.

tsimionescu 3y ago

Actually, there are cases where this is more or less unavoidable. For example, if you want a web socket server that is accessible from a browser, you need authentication, and can't rely on cookies, the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).

zer00eyz 3y ago
Authentication: Identify yourself Authorization: Can you use this service. Access Control/Tokenization: How long can this service be used for. I swipe my badge on the card reader. The lock unlocks. Should we leave a handy door stopper or 2x4 there, so you can just leave it propped open? Or should we have tokens that expire in a reasonable time frame.. say a block of ice (in our door metaphor) so it disappears at some point in future? Nonce tokens have been a well understood pattern for a long time... Its not that these things are unavoidable its that security isnt first principal, or easy to embed due to issues of design.
- bigiain 3y ago
  > Or should we have tokens that expire in a reasonable time frame. And that are single-use. (Your password reset "magic link" should expire quickly, but needs a long enough window to allow for slow mail transport. But once it's used the first time, it should be revoked so it cannot be used again even inside that timeout window.)
skissane 3y ago
> the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket). Put a timestamp in the token and sign it with a private key, so that the token expires after a defined time period. If the URL is only valid for the next five minutes, the odds that the URL will leak and be exploited in that five minute window is very low