Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You cannot simply publicly access private secure links, can you?

vin01.github.io

Post reply on HN
Print view View original

41–50 of 226 posts

Re: You cannot simply publicly access private secure links, can you?

#41

Post by QuinnyPig »

4death4 wrote: post #22
ta1243 wrote: post #4

Earlier quoted context omitted.

The problem is links leak. In theory a 256 hex-character link (so 1024 bits) is near infinitely more secure than a 32 character username and 32 character password, as to guess it https://site.com/[256chars] As there's 2^1024 combinations. You'd never brute force it vs https://site,com/[32chars] with a password of [32chars] As there's 2^256 combinations. Again you can't brute force it, but it's more likely than the 2^…

Passwords are always private. Links are only sometimes private.

Yup. There’s a reason putting credentials into url parameters is considered dangerous.

Re: You cannot simply publicly access private secure links, can you?

#42

Post by nkrisc »

empath-nirvana wrote: post #21
QuercusMax wrote: post #19

I've always been a bit suspicious of infinite-use "private" links. It's just security thru obscurity. At least when you share a Google doc or something there's an option that explicitly says "anyone with the URL can access this". Any systems I've built that need this type of thing have used Signed URLs with a short lifetime - usually only a few minutes. And the URLs are generally an implementation detail that's not d…

There's functionally no difference between a private link and a link protected by a username and password or an api key, as long as the key space is large enough.

There’s a big difference. The latter requires information not contained in the URL to access the information.

Re: You cannot simply publicly access private secure links, can you?

#43

Post by bachmeier »

internetter wrote: post #2

The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity,…

> The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers.

Is there a difference between a private link containing a password and a link taking you to a site where you input the password? Bitwarden Send gives a link that you can hand out to others. It has # followed by a long random string. I'd like to know if there are security issues, because I use it regularly. At least with the link, I can kill it, and I can automatically have it die after a few days. Passwords generally don't work that way.

Re: You cannot simply publicly access private secure links, can you?

#44

Post by bachmeier »

4death4 wrote: post #22
ta1243 wrote: post #4

Earlier quoted context omitted.

The problem is links leak. In theory a 256 hex-character link (so 1024 bits) is near infinitely more secure than a 32 character username and 32 character password, as to guess it https://site.com/[256chars] As there's 2^1024 combinations. You'd never brute force it vs https://site,com/[32chars] with a password of [32chars] As there's 2^256 combinations. Again you can't brute force it, but it's more likely than the 2^…

Passwords are always private. Links are only sometimes private.

Well-chosen passwords stored properly are always private. Passwords also tend to have much longer lifetimes than links.

Re: You cannot simply publicly access private secure links, can you?

#45

Post by rkangel »

victorbjorklund wrote: post #10

Can someone smarter explain to me what is different between? 1) domain.com/login user: John password: 5 char random password 2) domain.com/12 char random url If we assume both either have the same bruteforce/rate limiting protection (or none at all). Why is 1 more safe than 2?

This article is the exact reason why.

(1) Requires some out-of-band information to authenticate. Information that people are used to keeping safe.

On the other hand the URLs in (2) are handled as URLs. URLs are often logged, recorded, shared, passed around. E.g. your work firewall logging the username and password you used to log into a service would obviously be bad, but logging URLs you've accessed would probably seems fine.

[the latter case is just an example - the E2E guarantees of TLS mean that neither should be accessible]

Re: You cannot simply publicly access private secure links, can you?

#46

Post by koolba »

bachmeier wrote: post #43
internetter wrote: post #2

The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity,…

> The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Is there a difference between a private link containing a password and a link taking you to a site where you input the password? Bitwarden Send gives a link that you can hand out to others. It has # followed by a long random string. I'd like to know if th…

If there’s a live redirect at least there’s the option to revoke the access if the otherwise public link is leaked. I think that’s what sites like DocuSign do with their public links. You can always regenerate it and have it resent to the intended recipients email, but it expires after some fixed period of time to prevent it from being public forever.

Re: You cannot simply publicly access private secure links, can you?

#47

Post by wetpaste »

victorbjorklund wrote: post #10

Can someone smarter explain to me what is different between? 1) domain.com/login user: John password: 5 char random password 2) domain.com/12 char random url If we assume both either have the same bruteforce/rate limiting protection (or none at all). Why is 1 more safe than 2?

In the context of this article, it is that security scanning software that companies/users are using seem to be indexing some of the 12-char links out of emails which ends up in some cases on public scan. Additionally, if domain.com/12-char-password is requested without https, even if there is a redirect, that initial request went over the wire unencrypted and therefore could be MITM, whereas with a login page, there are more ways to guarantee that the password submit would only ever happen over https.

Re: You cannot simply publicly access private secure links, can you?

#48

Post by nmadden »

mikepurvis wrote: post #34
internetter wrote: post #2

The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity,…

Bit of a tangent, but I was recently advised by a consultant that pushing private Nix closures to a publicly-accessible S3 bucket was fine since each NAR file has a giant hash in the name. I didn't feel comfortable with it so we ended up going a different route, but I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request fo…

I wrote about putting secrets in URLs a few years ago: https://neilmadden.blog/2019/01/16/can-you-ever-safely-inclu...

Re: You cannot simply publicly access private secure links, can you?

#49

Post by masom »

ta1243 wrote: post #4
internetter wrote: post #2

The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity,…

The problem is links leak. In theory a 256 hex-character link (so 1024 bits) is near infinitely more secure than a 32 character username and 32 character password, as to guess it https://site.com/[256chars] As there's 2^1024 combinations. You'd never brute force it vs https://site,com/[32chars] with a password of [32chars] As there's 2^256 combinations. Again you can't brute force it, but it's more likely than the 2^…

You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce.

The one link won't be found quickly, but a bunch of links will. You just need to fetch all possibilities and you'll get data.

Re: You cannot simply publicly access private secure links, can you?

#50

Post by godelski »

There's a clear UX problem here. If you submit a scan it doesn't tell you it is public.

There can be a helpful fix: make clear that the scan is public! When submitting a scan it isn't clear, as the article shows. But you have the opportunity to also tell the user that it is public during the scan, which takes time. You also have the opportunity to tell them AFTER the scan is done. There should be a clear button to delist.

urlscan.io does a bit better but the language is not quite clear that it means the scan is visible to the public. And the colors just blend in. If something isn't catching to your eye, it might as well be treated as invisible. If there is a way to easily misinterpret language, it will always be misinterpreted. if you have to scroll to find something, it'll never be found.

Post reply on HN