5 ms·
But how many people will check in detail what‘s submitted? And again, how do you prevent that different users get different functionality?
by faebi 6y ago
But how many people will check in detail what‘s submitted? And again, how do you prevent that different users get different functionality?
- prepend 6y agoOnly a few need to check to see what’s submitted and serve as a canary for others. It’s possible some bad actor could do dumb stuff, but SSL helps in that at least the server would have a unique id. Personally the first time I used HIBP I checked the javascript that was running and read about what happened. It’s possible that someone could hack their server and replace the javascript with new bad versions. I don’t check anymore. But it’s unlikely, and a shared, common risk of using any site, I think. But the important thing with HIBP (and other sites) is that I never send them any sensitive information.
- jhardy54 6y ago> Only a few need to check to see what’s submitted and serve as a canary for others. I couldn't agree more. Even if you have root on their server and do a full audit, there's nothing to stop them from changing the code the moment you log out.
- mcherm 6y ago> But how many people will check in detail what‘s submitted? That's a valid criticism. It only takes one person finding clear evidence of problematic behavior to advertise that fact to the entire community. So long as a small fraction of people do actually check, the whole community will be fine. But if only a negligible number of people check it, then perhaps no one will be checking when it is abused. > And again, how do you prevent that different users get different functionality? Well, it depends on how the system is discriminating among users. To a great extent, that kind of abuse is prevented by anonymous users. You don't have to log into HIBP in order to use it. The system could still be discriminating by IP address, or even by various kinds of browser fingerprinting (including just collecting the advertising company cookies that so effectively eliminate anonymity for much of the web). Occasionally using TOR won't help against this -- a malicious operator could simply provide "clean" functionality to all TOR users. - - - - On the whole, things like, k-anonymous API design, making source code open, or having a small fraction of users checking for security issues all help a great deal and make it difficult for a malicious operator to abuse the system. But none of them are perfect. In the end it comes down to trust. Troy Hunt has EARNED that trust due to his openness, and in no small part by choosing to implement protections like these that he didn't need to implement, and I find that extremely persuasive. If you take steps to ensure that your CANNOT cheat your "customers", then that's pretty good evidence you aren't likely to be trying to cheat them.
- kungato 6y agoHow do we know if anyone is checking?
- joshspankit 6y agoAnother good question but since it’s trivial (opening the browser dev tools during a submission), we can assume a significant number. Doubly so because any service that says it’s secure gets a lot more scrutiny.
- jhardy54 6y agoYou can't verify. Even if you could, you can't ensure that the code will be replaced the moment you turn around. I investigated this thoroughly a few years ago, and the solution I came to is distributed computing. Join a peer-to-peer network an run the code directly on your own hardware or depend on someone that you actually trust. As far as I can tell there are no shortcuts that allow you to trust strangers with sensitive data.