Onionshare – Securely share a file of any size using Tor
github.com
github.com
Here's what I found when I googled for it: https://github.com/readevalprint/mini-django
I've actually been working today polishing up a skeleton app I use for my Flask apps for other devs to use -- still rewriting but I'll throw this out there since it's already pretty usable for small-to-midsized projects (MIT license):
https://github.com/esbullington/flask-bootstrap/blob/master/...
def check_auth(username, password):
global auth_username, auth_password
return username == auth_username and password == auth_passwordThe obvious thing that stands out to me is potential timing attacks: 'and' doing short circuit eval, and '==' exiting early when the first byte is non-equal (or the lengths are non-equal).
It doesn't matter if your connection is slow, all that matters is that latency is fairly consistent during the attack. You can use statistics to extract high-confidence data even from noisy signals, if you run the attack long enough to get lots of timing data.
They are not talking about the same kind of timing attacks. Deanonymization attacks require vastly less latency consistency.
https://docs.python.org/2/library/hmac.html#hmac.compare_dig...
Honestly, I don't know enough about timing attacks to be sure.
passed=true
for (i=0; i< len(auth_username); i++) {
if (i >= len(username) || auth_username[i] != username[i]) {
passed = false
}
}
for (i=0; i< len(auth_password); i++) {
if (i >= len(password) || auth_password[i] != password[i]) {
passed = false
}
}
return passed
And even if it keeps it constant time, a processor may end up running a function like this in non-constant time, due to caching and branch prediction effects.
Hashing the username (like you mentioned) and comparing
those character by character (like above) should yield the
exact same timing for any inputs.
For the comparison itself, I usually see |= and XOR being used and then the final value being checked to be non-zero, rather than a boolean. I think the theory is the compiler is a lot less likely the exit the loop early if you're accumulating with XOR versus a single branch flipping a boolean to be false.
Here's a good write-up with some sample code: http://codahale.com/a-lesson-in-timing-attacks/. Note in that write-up they are talking about timing attacks comparing HMAC results, but that is when the attacker has control over the HMAC result not the HMAC input. If the attacker provided value is being fed into HMAC with a secret key, then you are absolutely safe from timing attacks. If the attacker has control over the HMAC result, and you are checking if that HMAC is valid, then you are back to defending against timing attacks by trying to achieve a constant-time compare.
The only thing left to leak is the HMAC will clock differently based on the block-length of the input. But block size is rather coarse, and in this case you could limit inputs to be less than one block size in all cases.
Keep in mind that the username/password are just hex-encoded 128 bits from /dev/urandom, so they're not guessable at all without some sort of leakage attack, like a timing attack. And if anyone attempts to do a timing attack the person hosting the file will see all the requests scrolling down their terminal in real-time and can always hit ctrl-c.
There's also the bit about knowing the hidden service .onion to attack in the first place, which wouldn't be trivial to discover, especially since I envision these to mostly be very short-lived.
But all that said, this is great feedback. Keep it coming and feel free to open security issues on github.