Show HN: URL Canary – Get an alert when someone finds your secrets
31–40 of 122 posts
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#32FYI - I signed up and the email confirmation page showed me someone else's canary URL
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.
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#33Earlier 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
#34Maybe I don't understand the concept but why would you ever put a secret public?
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#35Earlier 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.
Given this kind of disaster potential, wouldn't it be a rather attractive option to use /dev/urandom?
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.
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#36I 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?
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.
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#37Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#38Similar idea than https://uriteller.io . This is nice way to check whether your end to end encrypted chat is really secure or not.
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#39Earlier quoted context omitted.
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.
Re: Show HN: URL Canary – Get an alert when someone finds your secrets
#40I 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! Jok…
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.