Comment by raxxorraxor | Hacker News Reader

Comment by raxxorraxor | Hacker News Reader

Did the URL contain a capability string? This is a key that only you posses ideally and the URL is only active for a limited time. This is how every [edit: most] password reset links work.

Yes, the URL is on the public net, but unknown for everyone aside from you.

> Can it really be considered safe, a public URL; just because it's long

Yes: https://www.w3.org/TR/capability-urls/

Depends on the implementation of course. Many use the format of a UUID like this: 07463cd8-3f1f-11ed-b878-0242ac120002, although you should NOT! use a UUID, only the format or better something else.

But it is considered safe provided the link is only valid for a limited time (3 months should still be ok).

This mechanism should regularly be reevaluated though. It is especially security mechanisms that can compromise it. Corporate mail & firewall security will see the link, might log it somewhere where it can be exposed, etc.

But the fundamental mechanism is considered to be secure.

edit: The requirements for it to be secure are that mail and http access is secured by TLS of course.

Thank you for the answer, I didn't know about these Capability URLs.

It's kind of security by obscurity I think. Still, if somehow somebody else gains access to a Capability URL, it cannot be considered an unlawful act. He could even claim that he was lucky enough to type a URL, which by coincidence gave him access to somebody else's personal data.

Not a lawyer but I would think since it is still a protected resource, the legal protections should apply too.

I get that it looks insecure, but it is extremely unlikely to hit the correct value. Here some more info:

https://en.wikipedia.org/w/index.php?title=Universally_uniqu...

This is for a 128(122) bit UUID, some capability URL use other and longer values. Depends on the implementation details and if someone catches your mail, the URL is exposed. There are some security concerns because URLs are usually not treated as a secret and are saved by your browser for example where it could by exposed to other parties.

But overall the mechanism is still a valid way to provide access to restricted resources without the user needing an account or login. This can happen for business because people generally don't want to register for every service. You could use a third party authentication provider, but can come with its own problems.

> although you should NOT! use a UUID, only the format or better something else

Why? Even the document you linked recommends using them...

Well, it depends. I just said it to not make it more complicated. Depends on the version of UUID and some versions according to specification have fixed bits at some points. This can be dangerous for a key to have. Their generation could also not be as random as required for a key. In practice many now do not recommend just using UUID anymore because that could mean one could deduce some parts of the key.

If so, you should use version 4 of an UUID, not 3, not 5, just 4. Because by specification that is the purely random one. Version 3 and 5 use MD5 or SH1 from an input to generate the ID as far as I know. In the vast majority of cases this also doesn't matter, but better to be sure. Perhaps I used too much caps for the NOT. If you use a solid random generator you should be safe. Just don't rely on a ready-to-use UUID-generator for cryptographic purposes.

Thank you for the thorough explanation. Makes sense.

Reply on news.ycombinator.com