It doesn't matter that it theoretically all happen in the browser. You can serve different versions to different IPs etc. Every heuristic in me would be screaming don't use that if I would have a need for such tool.
In this case its possible that the site encodes the data back in to the image but that seems unlikely.
A better example is Protonmail, a secure email service. It has a nice web client and there is an 3rd party desktop/electron version of the same size called Electronmail. While both essentially run identical code, the electron version is more secure because even Protonmail insert a backdoor for a single or # of users. They would have to at least publish the backdoor in the vanilla code at which point, the maintainers of Electronmail will probably raise the alarm.
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
The only way an attack vector is possible here is if you think GitHub themselves would maliciously inject an altered version of the code in the repo, and even then you'd be able to see the code and network requests in your developer tools.
See also https://haveibeenpwned.com/Passwords.
Just distribute the code for local execution? Sure, it's less accessable for the target audience, but it is more transparent.
But what else is new? Most users are willing to sacrifice privacy and security for convenience. That's how we got into this whole mess.
https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...
I mean, I get what you mean, but this is literally what's already happening. It's distributed via HTTP, and executed in your browser. You can save it (Ctrl-S, still a thing browsers do), and -- since it's distributed in source form -- easily inspect it, or reopen it later, in a different browser on a different computer. A zip file of the same thing is available on the repo (it's a zip of the repo).
If you don't trust that it won't access the web, disable your internet while running it or some such, as with other code you don't trust. If you don't trust it to mess with your files, well, you're in luck because modern browsers are probably the best audited sandbox out there.
I say I get what you mean, because most people won't do any of it. Instead of saving the page and running what they trust or have verified to be a safe snapshot of the page, they'll reopen the hosted version, trusting that it's still safe, even though the page may have been replaced with one that does upload their files.
Users are disclosing to the website what they hope has not been discovered by someone else -- e.g., usernames and email addresses, or in this case photos, they hoped to keep private. Unfortunately, the website is "someone else".
(Sorry for commenting on you twice in this thread--I promise I'm not trying to follow you around. I'm all about dissecting the quality of a system or toolchain! A false sense of security can be more dangerous than naïveté! Caution and skepticism are often our only protection! Trusting random websites is Not a Good Idea! But, security tools average people can't use are also meaningless here.)
https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
Your question is on target--one I've wondered myself--but I've come to the conclusion that it isn't for people who already have the sense not to put their passwords in random forms on the internet.
I can only assume it has 2 main uses:
1. Poke (some) holes in the bubbles of people with dated password hygiene practices (and a poor sense of how good other humans are at helping attackers reduce the possibility space) by giving them a playground to make new passwords against for a while.
For example, I decided to enter "silverfish3" in the form because I know more than one person who still uses <noun><number> passwords that are multiple characters shorter than this one. It's still turned up in the database 40 times. "dichotomy14" hasn't been pwned yet, but "dichotomy7" has already been pwned 5 times.
You don't have to use a real password of your own to discover that your schema is well explored.
2. I can only hope HIBP password search has scared a few thousand of the kind of person naive enough to fill in the form with a real password straight.
I did not suggest distributing an executable. I suggested distributing code, so that the user could audit it before execution.
I did not realize this tool executed all of its logic in the client when I made that post. It is rare to find websites with plainly-written, unobfuscated, uncompressed, vanilla Javascript that don't rely on any server-side processing.
HIBP offers you a way to validate a password has been compromised, HIBP does not offer you a way to determine it has not been compromised or is otherwise suitable for use. It’s a service for excluding compromised passwords from use.
It sends a GET request for "https://api.pwnedpasswords.com/range/89F5D"
and gets back 548 rows of the form:
001F74CD3E241B7820C996DA4FB3BDF9FE7:2
...
54C7FB299EC06A0B979C5DE14F1AE61F653:40
...
FFE6FF5698CEC527CD18269D1B7697C8743:1
Note that middle example row with ":40" at the end? Prepend "89F5D" from that GET request the javascript generated to that row's contents "54C7FB299EC06A0B979C5DE14F1AE61F653"
Now compare that to what you get when you run this (This is a macOS specific invocation of the command, but something very similar should work pretty much anywhere):
$ echo -n "silverfish3" | openssl sha1
(stdin)= 89f5d54c7fb299ec06a0b979c5de14f1ae61f653
You might (perhaps rightly) not trust Troy's site to not switch out the javascript underneath you, but you _can_ trust the API, and could always run:
curl https://api.pwnedpasswords.com/range/89f5d
Or, if you're testing that "dichotomy7" password:
echo -n "dichotomy7" | openssl sha1
(to get (stdin)= 772be5bd14dc626ec7fa952b51ae28c482e92d39)
then:
curl -s https://api.pwnedpasswords.com/range/772be | grep -i '5bd14dc626ec7fa952b51ae28c482e92d39'
will show you your result of that dichotomy7 password having been seen 5 times.
You've only revealed the first 5 characters of the 40 character sha hash to the server. That might have been one of the ~500 passwords with that same hash, or any of the rest of the 150 bit space of other strings that hash to that prefix that are not part of their database.
I would be perfectly happy running echo -n "{{a real valuable password of mine}}" | openssl sha1 locally and then feeding the first 5 characters of that into "random apis on the internet".
But it doesn't matter what you or I can prove the site does or doesn't do with our passwords; my dad or aunt shouldn't type their passwords into random forms on the internet. Whether it tells them it's using k-anonymization or not.
You still wouldn't pop your dev tools open but then type your real password into a random form on the internet before you'd kicked the API-tires with some fakes.
Anyone who isn't prepared to kick the tires and hasn't established a trust relationship has no business doing it.
How does this work?
2 cases:
1. I know password P is compromised. I check it in HIBP. If compromised, great, but I already know that. If not, well, too bad. I still can't use it because I know it's compromised. - decision doesn't depend on the result of HIBP.
2. I don't know if P is compromised. I check it in HIBP. If compromised, I don't use P. If not, I don't use P because I already put P in a text box connected to the internet. - decision doesn't depend on the result of HIBP.
Don't get me wrong, I'm well aware of the value of HIBP. I'm just arguing about this particular use case.