21–30 of 72 posts
The biggest problem is being prone to misinformation. There's nothing to prevent people from posting arbitrary e-mail lists to pastebin, with purported matching passwords, as an effort to provoke your service to cry wolf.
A few suggestions to harden the service:
- provide integrity when sending the message by including a PGP signature. what's to stop someone from running an e-mail server and spamming mass e-mail lists with message headers that spoof your mail domain, and proclaim bogus security lapses?
- in general, e-mail itself is not assuredly secure. sending people an e-mail is not enough, since the message might be intercepted as plaintext, and altered in transit. furthermore, those intercepting the e-mail might scoop up credentials and use them. if your service is a reliable source of working credentials, who better to attack? maybe you risk making the problem worse?
- consider hosting a secure web page over SSL, and mail links to your site. if your service gains a positive reputation, users might be able to acknowledge past leaks, but elect to receive further notices if other leaks recur elsewhere. maybe users can see links to the source someone is using to post their info, and whether the situation has been remedied by a take-down. this might be a questionable activity: if you send people to that same breach, will they look at the same list and abuse other users on the list? but what better way to demonstrate the breach?
- provide a means to verify the level exposure. what if someone's account was listed for 24 hours, and then the leak was taken down. they might still wish to know they were exposed, so they can take action. also, is the resource you're linking to confirmed as related to a known/verified data breach? who confirmed that this was a real breach of security? are you a first responder to the leak? has the leak been responsibly disclosed to the providers of the accounts tied to the leaked passwords?
> Including one request to F k off. If someone had just sent me an email letting me know that my email and password are out there in the wild, "fuck off" would not be my first reaction. That's just rude.
cached version -> http://webcache.googleusercontent.com/search?q=cache:tQP6ur9...
Thanks :) Since it says "Error establishing a database connection", I wonder if someone misused the password of their database?
Did you track open rates? I would be curious to see what those numbers look like.
Is there any reliable way to do this? Most mail clients will block receipt-type stuff by default...
> Including one request to F k off. If someone had just sent me an email letting me know that my email and password are out there in the wild, "fuck off" would not be my first reaction. That's just rude.
Earlier quoted context omitted.
Is there any reliable way to do this? Most mail clients will block receipt-type stuff by default...
I believe the trick is to put a hidden, 1px image in the email. Then you can track how many times it was requested.
Earlier quoted context omitted.
Is there any reliable way to do this? Most mail clients will block receipt-type stuff by default...
I believe the trick is to put a hidden, 1px image in the email. Then you can track how many times it was requested.
This is a cute experiment, but unfortunately the integrity of the service is is easily corrupted. The biggest problem is being prone to misinformation. There's nothing to prevent people from posting arbitrary e-mail lists to pastebin, with purported matching passwords, as an effort to provoke your service to cry wolf. A few suggestions to harden the service: - provide integrity when sending the message by including a…
This is a good point, but wouldn't use of SPF/DKIM solve this too? I think email servers are able to understand the SPF records and DKIM-Signature header and hence more accurately classify the emails as spam (if appropriate) which seems like a useful benefit.