Asymmetric PAKEs level the playing field considerably.
The way we typically use passwords (you just outright tell the other party the password and we hope that's fine) is terrible security design. But everything about passwords is pretty terrible, their only "benefit" is that they're easy which is often undone by measures layered on top to try to deliver security, such as password rotation policies.
I was thinking about how the government still collects a lot of forms on paper. On the one hand, it's costly and inefficient waste. On the other hand, no one from Bulgaria can sneak off with all of the VA's paper forms without someone noticing the long line of semi-trucks driving away from the building…
FWIW I have some paper forms that they couldn't reproduce when I submitted a FOIA request. It's just everything post-2000 when the web based system was first instituted.
I wonder how this fix behaves with '\r' on all platforms. Obviously the primary systems (windows/osx/linux/bsd) all use \n or \r\n, but I'm wondering if Git has been ported to more obscure systems that only use \r [0], and how this fix would behave there.
That was discussed before the fix, but it doesn't matter. The helper protocol specifies a raw newline as the delimiter, and both sides of the conversation parse on that.
Hmm, it makes sense to catch the error when writing, but I wonder why not fix the parser as well? https://example.com?foo=bar is a valid URI reference per RFC 3986 and doesn’t look so malicious yet it’s still parsed wrong. (I didn’t bother to track down and read the parser code.)
21 comments
[ 2.9 ms ] story [ 16.5 ms ] threadThe way we typically use passwords (you just outright tell the other party the password and we hope that's fine) is terrible security design. But everything about passwords is pretty terrible, their only "benefit" is that they're easy which is often undone by measures layered on top to try to deliver security, such as password rotation policies.
But this was still a dumb bug.
This is your reminder that there is no such thing as computer security in the year 2020. Treat your computers accordingly.
If only...
Unauthorized access to cameras in Safari on macOS and iOS - https://www.ryanpickren.com/webcam-hacking
And another one related to URL parsing:
The unexpected Google wide domain check bypass - https://bugs.xdavidhu.me/google/2020/03/08/the-unexpected-go...
Malicious URLs may cause Git to present stored credentials to the wrong server - https://github.com/git/git/security/advisories/GHSA-qm7j-c96...
..And the commit that fixed it:
https://github.com/git/git/commit/9a6bbee8006c24b46a85d29e7b...
[0] https://en.wikipedia.org/wiki/Newline#Representation
Hmm, it makes sense to catch the error when writing, but I wonder why not fix the parser as well? https://example.com?foo=bar is a valid URI reference per RFC 3986 and doesn’t look so malicious yet it’s still parsed wrong. (I didn’t bother to track down and read the parser code.)