You might think about embedding bounties in crypto blockchains. For example, create BTC wallets that can be unlocked using a secret sitting next to (or steganographically embedded in) the secret you're trying to protect. This gives the person uncovering the secret an incentive to activate the canary. {RI,MP}AA are apparently doing this with their music and movies, so they know when they are showing up on pirate sites.
That's some awfully pessimistic and dehumanizing language. I just consider it to be paying someone for the trouble rather than jumping straight to "exploiting greed."
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.
Strange. I feel only a slight negative connotation of "greed". Nothing to be ashamed of or to condemn. Maybe some meaning is lost in translation to my language.
I think this is a great idea and a great use of a BTC/LTC wallet. Breach notification often doesn't happen in a timely manner, and building a solution like this let's me, the consumer, get notified even when the vendor with the secrets doesn't send the notification.
Is there a source that it was definitely claimed? The BTC have moved, but the site notes "[i]n 2018 we will likely reuse most bitcoins for other projects", and the transaction (splitting into two amounts of 9BTC and ~1BTC) aligns with this Tweet from December:
> PSA: the bitcoin piñata will be reduced by a large amount, the owner who lend the 10 btc wants to spent 9 on useful projects
"This challenge started in February 2015, and will run until the above address no longer contains the 10 bitcoins it started with, or until we lose interest. In 2018 we will likely reuse most bitcoins for other projects."
You’ll notice someone gained access to your system (because the money will disappear) but you’ll have zero clue how they did it. Also, how do you prevent an employee from stealing the funds for themselves?
There’s a reason companies use bug bounty platforms instead of just having a bunch of bitcoins lying around.
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.
Bytes::Random::Secure::Tiny seeds itself from /dev/urandom, I just need to make sure to initialise it on first use, instead of when my program first starts (which I've now done).
In general I suspect if anything you'd be more likely to mess it up by reading bytes from /dev/urandom manually than by using a library.
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.
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.
I though the main issue of reading bytes from /dev/urandom was performance (ignoring the issue of ensuring /dev/urandom has been initialized since boot.)
So instead, we use them to seed CPRNGs, and use them for speed.
This implies that you should probably invalidate all URLs created before you applied that mitigation, right? Or do you have some way (logs?) of knowing which ones were compromised?
I don't understand this. Someone just visits the URL and I get a email notification? If it's supposed to be secret, how does the script knows if the visit is OK or not, sending me the notification only when it's OK? Are the good guys supposed to know this is a sort of "honeypot" URL and not visit it?
Put a URL in a firmware image that is never called by your device/app.
Monitor the URL for access. You then receive an alert that someone accessed the URL.
This gives you a real-time notification that a reverse engineer has looked at your firmware. It also gives you an IP address. So you now “know” that someone might try to hack your device. And you also have an IP address.
This is a billion dollar security play!
Jokes aside. It is a good concept for IoT firms who have a security advocate, but no budget. Would help persuade people that there are hackers targeting their devices/apps with quantifiable data of degrading value.
Huh. That’s...a good idea. The idea has to be developed further though. This has to be deployed on different domain names and with full content control on the web pages.
I guess that’s all doable with the “private server with root access” under enterprise pricing. What a great way to precisely measure cover time. You could inject arbitrary URLs into an application to see if your API has been reverse engineered.
I presume the idea is to make the URL appear to be part of the standard API (and maybe even does something useful to induce use?), but it is never actually called by a legitimate application?
I’m speaking specifically about the case where someone is trying to reverse engineer a private API from an application. Then interacting with an API endpoint will necessarily trigger the canary.
Having retrieved API secrets offensively, and overseen secret rotation defensively, I’d say it would be a game changer. It’s an excellent idea to automate this discovery with an alarm. The current discovery system is either an internally developed, half-baked version of this that comes from sophisticated logging, or manual oversight.
Friendly feedback, coming from a reverse engineer: the commenter who also answered this question gave a really good, concrete example of how this could be used in the context of DRM. When I visited your page I was initially perplexed as to why you’d want any of this. You should include a specific example of how this service delivers value, and the reverse engineering example is a good one.
Semi related asking the wizard of HN. I recall reading a similar trick whereby one can embed a github key/token/api key/??? In a source file in one's repository and then if your code ever is stolen and pushed to github then you will receive a notification because github will revoke the token. Does this or similar ring a bell for anyone?
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.
Not true. I know bitly and googl have those info pages, so I'll check them out when I am curious but am not sure whether I want to alert whereever it leads. I know I'll get more info at best, and don't lose anything at worst. For random URLs, I guess I could try whois lookups, but I'd be much more likely to just check it out than with a short URL which is easily checked out.
If seeing that the bit.ly URL redirects to a known-urlcanary domain would put you off visiting the URL, then seeing the raw known-urlcanary domain (not behind bit.ly) would also be enough to put you off visiting it.
So, doesn't this mean you need to have a bunch of domains, none of which look like urlcanary domains? If you hide behind something like namecheap's whoisguard (customer, not affiliated with them), that would do the trick, right?
If you can use any domain you like, that is great.
MyURL.com/101/passwords /private /logins
Is the idea that you'd embed this in a way that it is automatically triggered? Or that you would leave it in plaintext somewhere and assume someone would eventually visit it if they were snooping around your stuff?
Sorry to offer unsolicited advice, but are you sure you wanna use a fixed IP for that? Seems more reasonable to ask people to CNAME to a domain you guarantee will always point to the correct servers.
This means you don't break the system when you move IP address. Moreover, should you ever need to, you can round-robin the domain for either reliability or load-balancing (though I doubt that would be necessary).
The bit.ly approach might result in false positives as the namespace for bit.ly links is quite easy to iterate over (assuming you don't use a custom link).
Also, doesn't bit.ly access a URL to pull a title or generate a preview? This would send a click through to the canary as well.
A quick test using Zapier's webhook functionality tells me I can duplicate this with their platform. Doesn't seem to work with link shortener, but I have the sense more time invested on that will yield a result. So, I think the concept has merit but you're off center of the target and much more value is required.
I imagine there's a lot of value to be found in a dashboard, or generally in managing these canaries. Which canary was deployed where, how often are they triggered (with the ability to mark some instances as false alarm) etc.
But of course that heavily depends on the use case
So what happens when the three offered domains become widely known to be fake? Can this service be federated and use custom domains or is it just another game of whack-a-mole?
Not to be overly negative, but if you're going to the trouble of pointing a custom domain to this service, couldn't you just write a quick PHP script that mail()s out when it's accessed? As far as I can see, the only advantage of using this third-party site is convenience, a custom domain makes it much less so.
Will the canary URLs always be to the same domain? If so, can't I circumvent this just by using custom dns locally to map that domain to somewhere else, like localhost? If it's not a domain, but an IP address, can't I just route that IP somewhere else?
There are currently 3 domains available. If this takes off I could do something like mailinator (offer the user a small selection, but never reveal the full list at once).
You can also register your own domain and point it at my server and your canary will work just fine on that domain.
If you're playing at a high enough level that you've specifically blackholed URL Canary traffic by IP address, then you're a worthy adversary. And additionally, that is a splendid problem for my project to have.
On the enterprise tier you even get your own server with its own IP address, so there should be nothing linking it to URL Canary at all. (Although the enterprise tier is extremely expensive, and if anyone buys it I will probably panic).
This is neat.. Its currently a single type of token (ie. a URL).
If you check out https://canarytokens.org you will notice the ability to create several others (be notified when someone resolves an IP address, be notified when someone opens a file, be notified when someone views a QR code, etc)
I'd really like to see a generalisation of this idea to any personal/private data stored in any database. Any time a piece of 'your' data (e.g. a medical record) is accessed, you get an alert. There could be an industry of alert brokers that decide if the alert is important or not - you might employ one, or write your own, or choose to look at every alert. While it would require a big change to how we store data, I suspect that the changes required to be GDPR compliant start going in this sort of direction.
Is following a URL common practice for someone who accesses documents? I mean if I come across a repository, my first inclination isn't to find all of the hidden URL's and chase them.
How does a potential customer know how effective this is? How do you even know that it's effective for your personal use case as described https://urlcanary.com/about ?
How many attackers are going to click that link or any link for that matter? Seems the value prop of the product is based on the assumption that folks will click. Maybe it's a solid assumption. I just can't see the evidence for it.
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 problem in a simple way but it's still just as nondeterministic as without this solution IMO.
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.
It can be useful anywhere you have sensitive information that you wouldn't want to fall into the wrong hands, or more specifically that you would want to find out if it did.
It could go in backups, in your git repository, bug tracker, internal wiki, etc.
For an average non-techy, I don't know... they might want to put one in their diary?
For any web/cloud service, I think this might be easily triggered when the service is trying to be helpful. I.e. when fetching previews, displaying in/active links, etc...
Nice! I've often considered implementing a service like this at the DNS level. DNS would be ideal because it would work for more services, not only HTTP.
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.
I'd recommend just installing it and turning on a couple of the built-in filters by editing /etc/fail2ban/jail.local to see how it goes together. See the comment at the top of /etc/jail.conf as well and check out 'man jail.conf'.
Essentially to do the same thing as URL Canary you'd set up an action that only emails and trigger that with a custom filter that scans your web server's access log for accesses to a particular URL.
Dropbox is not a devs-only product, given that eg. the CEO might want a personal Dropbox folder, or one might need a shared folder between the marketing team and the developer team (and even then, at the enterprise level it is not unheard of to use simpler alternatives like SFTP/NTFS shares).
Canaries on the other hand are exclusively used by technical people, who won't mind developing and spinning up a tiny honeypot.
