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…
Show HN: URL Canary – Get an alert when someone finds your secrets
111–120 of 122 posts
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#112Earlier 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.
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#113Earlier 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?
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#114Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#115Earlier 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?
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
#116Earlier 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...
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
#117Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#118Earlier 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?
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
#119given the options are 3 domains to choose from: 1. emotionalrec.com 2. factwisdom.com 3. tdurl.uk Smart thief simply won't follow the link.