5 ms·

If your security depends on someone not walking your DNS zone, you're doing something wrong. If your security depends on someone not guessing a URL, shortened

If your security depends on someone not walking your DNS zone, you're doing something wrong. If your security depends on someone not guessing a URL, shortened or not, you're doing something wrong.

morgante 11y ago
> If your security depends on someone not guessing a URL, shortened or not, you're doing something wrong. Why? Done properly, a secure URL should be as long and contain as much entropy as a strong password. Are all systems which depend on someone not guessing your strong password wrong? Are practically all encryption schemes wrong?
- danielweber 11y ago
  URLs leak in a bunch of ways. Cached in browsers and proxies, sent in referers, sent in toolbar requests, logged in access.log files. I'm not saying that it's necessarily wrong to use a long URL as security; sometimes the problem constraint means that is the only way to do it. I've done it on rare occasion. But I also made sure that management knew there was a risk here.
  - rkangel 11y ago
    If that URL is being sent over an HTTPS link (which of course it should be) then the only two points that can log/cache it are the browser at the local end, and the server at the remote end. The latter is up to server design, the former is an interesting point. Browsers are unlikely to cache get parameters, but these things might end up in history etc..
    - jessaustin 11y ago
      The "Referer" header can also leak URLs.
- jessegreathouse 11y ago
  Because access to that resource can be replicated by simply viewing network traffic logs. Sending authorization info in the headers over SSL would be much more safe.
  - morgante 11y ago
    First of all, any secure resource should only be accesses over SSL so I assume that. The path is exactly as secure as authorization headers. Network logs will not show the path of SSL requests (it's encrypted).
    - zaroth 11y ago
      URL based Bitcoin wallets proved this not to be the case. URLs get picked up by Omnibar, Skype, etc. they find their way into search results... I wouldn't even trust secret material in the fragment-id even though that in theory is safer.
      - ikeboy 11y ago
        Doesn't excluding them in robots.txt solve the search engine problem?
        _Understated_ 11y ago
        Following the rules laid out in a robots.txt file is optional. The reputable search engines tend to play by the rules but dodgy ones? Not so sure.
        ikeboy 11y ago
        The dodgy ones don't have access to the URLs. The example was Skype links: if Microsoft scrapes those, they'll follow the rules and not make them available in searches. If you give your link to a dodgy search engine, you've lost.
    - deleted 11y ago
      [deleted]
- FLUX-YOU 11y ago
  He's saying it shouldn't be the only layer of security.
  - barrkel 11y ago
    How many layers of security should there be when you give someone driving directions to the abortion clinic?
- IanCal 11y ago
  > Are all systems which depend on someone not guessing your strong password wrong? Are practically all encryption schemes wrong? No, but if your security system has a password and only one account shared by everyone where the password is shared as plain text (typically just emailed from person to person) without any sort of user access logging then it's got major problems. With just a URL you have no idea who has access and the only way of revoking access to anyone is to permanently move the resource and then get back in contact with everyone who should have access by sending the new "password" around. > Are practically all encryption schemes wrong? An encryption scheme that involves the users sharing the only password through far less secure channels?
jiiam 11y ago
I would not be so hard on the matter, but yes, making private files available by url only seems like a bad security habit. Still, sometimes one wants to avoid Registration Wall to enhance usability (doodle.com is a nice example). This is to say that the whole url-shortening business should still be improved, even though you're probably not going to use it for your private stuff where you want access control.
Pxtl 11y ago
Honestly, there's something to be said for "shared passwords" for cases like this. I know that mathematically a public password adds no actual security over the long URL, but they're unlikely to be embedded in the link and propagated automatically as easily. But google only offers sharing write-access by account or publicly, not "public with password". I should be able to just say "here's the link, the password is burp441toaster, no spaces all lowercase".
__david__ 11y ago
Password reset links are the widespread rebuttal to your statement.
- cookiemonsta 11y ago
  they are one time use though
waynecochran 11y ago
Yes! Just using longer URL's is just security though obscurity. Which just gives a "false sense" of security.
- nommm-nommm 11y ago
  That's not what security through obscurity means. It's very possible for "unique urls as a password" to obey Kerckhoffs' second principle. Craigslist does this and it's a great system for a Craigslist post. You can sign up for an account if you want but you can also post without an account and you get a unique url as a password to edit or delete your post. Craigslist posts are only good for 30 days and someone deleting your Craigslist post isn't the end of the world. It's very possible to use urls as a password securely, password reset emails do it all the time.
  - waynecochran 11y ago
    Password reset tokens through email has always troubled me. Unless the email content is encrypted (and almost never is) then that token is exposed (imagine a compromised email server that harvests these tokens). Usually these things are time limited and you can know if another entity reset your password but it may be too late at that point.
tedmiston 11y ago
In this case, Facebook is "doing something wrong" with every photo URL.

If your security depends on someone not walking your DNS zone, you're doing something wrong. If your security depends on someone not guessing a URL, shortened or not, you're doing something wrong.

morgante 11y ago

> If your security depends on someone not guessing a URL, shortened or not, you're doing something wrong. Why? Done properly, a secure URL should be as long and contain as much entropy as a strong password. Are all systems which depend on someone not guessing your strong password wrong? Are practically all encryption schemes wrong?

danielweber 11y ago
URLs leak in a bunch of ways. Cached in browsers and proxies, sent in referers, sent in toolbar requests, logged in access.log files. I'm not saying that it's necessarily wrong to use a long URL as security; sometimes the problem constraint means that is the only way to do it. I've done it on rare occasion. But I also made sure that management knew there was a risk here.
- rkangel 11y ago
  If that URL is being sent over an HTTPS link (which of course it should be) then the only two points that can log/cache it are the browser at the local end, and the server at the remote end. The latter is up to server design, the former is an interesting point. Browsers are unlikely to cache get parameters, but these things might end up in history etc..
  - jessaustin 11y ago
    The "Referer" header can also leak URLs.
jessegreathouse 11y ago
Because access to that resource can be replicated by simply viewing network traffic logs. Sending authorization info in the headers over SSL would be much more safe.
- morgante 11y ago
  First of all, any secure resource should only be accesses over SSL so I assume that. The path is exactly as secure as authorization headers. Network logs will not show the path of SSL requests (it's encrypted).
  - zaroth 11y ago
    URL based Bitcoin wallets proved this not to be the case. URLs get picked up by Omnibar, Skype, etc. they find their way into search results... I wouldn't even trust secret material in the fragment-id even though that in theory is safer.
    - ikeboy 11y ago
      Doesn't excluding them in robots.txt solve the search engine problem?
      - _Understated_ 11y ago
        Following the rules laid out in a robots.txt file is optional. The reputable search engines tend to play by the rules but dodgy ones? Not so sure.
        ikeboy 11y ago
        The dodgy ones don't have access to the URLs. The example was Skype links: if Microsoft scrapes those, they'll follow the rules and not make them available in searches. If you give your link to a dodgy search engine, you've lost.
  - deleted 11y ago
    [deleted]
FLUX-YOU 11y ago
He's saying it shouldn't be the only layer of security.
- barrkel 11y ago
  How many layers of security should there be when you give someone driving directions to the abortion clinic?
IanCal 11y ago
> Are all systems which depend on someone not guessing your strong password wrong? Are practically all encryption schemes wrong? No, but if your security system has a password and only one account shared by everyone where the password is shared as plain text (typically just emailed from person to person) without any sort of user access logging then it's got major problems. With just a URL you have no idea who has access and the only way of revoking access to anyone is to permanently move the resource and then get back in contact with everyone who should have access by sending the new "password" around. > Are practically all encryption schemes wrong? An encryption scheme that involves the users sharing the only password through far less secure channels?

jiiam 11y ago

I would not be so hard on the matter, but yes, making private files available by url only seems like a bad security habit. Still, sometimes one wants to avoid Registration Wall to enhance usability (doodle.com is a nice example). This is to say that the whole url-shortening business should still be improved, even though you're probably not going to use it for your private stuff where you want access control.

Pxtl 11y ago

Honestly, there's something to be said for "shared passwords" for cases like this. I know that mathematically a public password adds no actual security over the long URL, but they're unlikely to be embedded in the link and propagated automatically as easily. But google only offers sharing write-access by account or publicly, not "public with password". I should be able to just say "here's the link, the password is burp441toaster, no spaces all lowercase".

__david__ 11y ago

Password reset links are the widespread rebuttal to your statement.

cookiemonsta 11y ago
they are one time use though

waynecochran 11y ago

Yes! Just using longer URL's is just security though obscurity. Which just gives a "false sense" of security.

nommm-nommm 11y ago
That's not what security through obscurity means. It's very possible for "unique urls as a password" to obey Kerckhoffs' second principle. Craigslist does this and it's a great system for a Craigslist post. You can sign up for an account if you want but you can also post without an account and you get a unique url as a password to edit or delete your post. Craigslist posts are only good for 30 days and someone deleting your Craigslist post isn't the end of the world. It's very possible to use urls as a password securely, password reset emails do it all the time.
- waynecochran 11y ago
  Password reset tokens through email has always troubled me. Unless the email content is encrypted (and almost never is) then that token is exposed (imagine a compromised email server that harvests these tokens). Usually these things are time limited and you can know if another entity reset your password but it may be too late at that point.

tedmiston 11y ago

In this case, Facebook is "doing something wrong" with every photo URL.