Live data from Hacker News

Show HN: URL Canary – Get an alert when someone finds your secrets

urlcanary.com

111–120 of 122 posts

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#111
post #99
post #98

Earlier quoted context omitted.

The value lies in sometimes demonstrating a channel is insecure. It won't always do so. Obviously the converse--proving a channel is secure--is much harder. I don't think it has commercial value really. But for social awareness, showing that mail, or notes, or storage providers aren't always as private as you'd hope, that's where the value is.

But it demonstrates nothing if no one clicks. The channel may be insecure, compromised and no one knows - not the author or the parties who are supposed to have the secrets. I see what he's trying to do, but this isn't the way I don't think. Mathematical proofs that verify that a payload is observed, opened, or accessed work. They are deterministic. They are also way more complex. I think this is trying to solve a pr…

Absolutely. But if you have the choice between a) not knowing 100 pct of the time, and b) knowing for certain it's not private X pct of the time, for unknown X probably not 0, you'd want b. You will have more information by trying.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#112

Earlier quoted context omitted.

You can preview bit.ly links by appending a + to it.

But if you are already suspicious enough that you want to do that, you were never going to click on the original URL anyway, so it's no worse than not using bit.ly.

It's easy to integrate in a scraping script though, which I thought was what this was supposed to combat.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#113
post #102
post #77

Earlier quoted context omitted.

Since the person profiting is someone who obtained the secret through shady means - either breaking into an insecure system, or taking advantage of their access to a system which doesn't encrypt passwords - I don't consider it pessimistic or dehumanizing to describe the behavior as greed.

Greed is a subjective term. The company who is charging money could be described as greedy for making a profit when they could have lowered the price to remove any excess profit. Why is the person who understands and uses the system in a way it wasn't intented greedy?

Because they're stealing secrets from people? I confess I'm confused why this is confusing. The exercise here is to know when something is public that you want to keep secret. The proposed solution is to make the secret something have value independent of its secretness, to tempt those that stole the secret to obtain that independent value. I'm fine attaching "greed" to profiting from stealing secrets.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#114
post #34
post #31

Maybe I don't understand the concept but why would you ever put a secret public?

You don't. You put it in a thought to be private place but you'll find out if it gets public at some point that way.

But why host it somewhere reachable at all?

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#115
post #114
post #34

Earlier quoted context omitted.

You don't. You put it in a thought to be private place but you'll find out if it gets public at some point that way.

But why host it somewhere reachable at all?

It's a canary, it should ideally never be triggered but in case it does you want to know about.

Another way would be to put a fake user in your users database and then watch password leaks and see if it shows up. Then you know you've been breached. It should never happen but if it does it's good to know.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#116
post #85

Earlier quoted context omitted.

How exactly can one mess up reading bytes from `/dev/urandom`? Serious question. Open the file. Read from it. If no failures on open or read, you have random bytes. In essence, there is already a library for this: `open` and `read`, which seems to be the same API surface area as this library.

Here's all the ways this can possibly go wrong: https://insanecoding.blogspot.com/2014/05/a-good-idea-with-b...

Most of these are ridiculous.

First, the author mentions that a `read` from urandom can be interrupted. I am unaware of any system where this is actually possible. And even if it were, the author's original code (and my description of an implementation) already works! The `read` call will return an error, and that error is handled. His "improved" code is simply an optimization around retrying from this device, but it's not an improvement in safety.

His second argument is that /dev/urandom might not have enough randomness in it. This is, quite simply, not a concern for anyone not writing code for specific embedded devices or for extremely early in the kernel boot process. Anyone who is writing code for these environments is almost certainly already aware of these limitations. And even then, using a library like the one the GP is using doesn't actually help, since it's virtually guaranteed to just be reading bytes from `/dev/urandom` for its seed in the first place.

The rest go into situations that — quite frankly — border on ludicrous. If someone has replaced your `/dev/random` with `/dev/zero`, you have already lost and there is nothing you can or should reasonably do besides nuke the machine from orbit.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#117
post #2

This is neat. For added security, maybe better to hide the canary URL in a bit.ly link? Someone might know your 3 URLS.

You can preview bit.ly links by appending a + to it.

If you preview a link, wouldn't it then require the bit.ly to fetch it? Or does bit.ly serve a cached copy?

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#118
post #93

Earlier quoted context omitted.

That's not good! Taking a look. EDIT: I believe it's because the CSPRNG state ( https://metacpan.org/pod/Bytes::Random::Secure::Tiny ) was created before the process forks, so they shared the initial state and generated the same token. I've reduced it to 1 worker pending an actual fix. Sorry about that, and thanks for pointing it out.

+1 for using Perl Care to share your stack?

Hey, sorry for the late reply. Not sure if you'll read this...

It's mostly http://mojolicious.org/

SQLite for the database (for now; that'll change if it gets too big), and nginx as a reverse proxy in front of Mojolicious. CentOS 7.

Re: Show HN: URL Canary – Get an alert when someone finds your secrets

#120

how does this differ from https://canarytokens.org/generate ?

Very little! Although the generated URLs don't have "canary token" in them.

Canarytoken allows you to download a docker instance, so you can host the server on any domain you like.
Post reply on HN