362 karma · joined March 9, 2012
Original: http://flong.com/projects/yellowtail/ JS Port: https://github.com/n1ckfg/yellowtails Demo: https://n1ckfg.github.io/yellowtails/p5js/
In any case, I think it's safe to say that 'pornin knows more about writing safe C code (and dealing with strange compiler behavior) than almost anyone.
* Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.
"And now this thing works for the NYTimes."
and after an initial edit, it says:
"And now this... 'person' works for the NYTimes."
For example, one implementation of SRP I looked at used 8-digit codes (e.g. 12345678) to connect new devices to a network. Eight digits was enough to prevent brute-forcing by repeatedly sending codes to the server, but not enough to prevent an attacker from MITMing the connection and brute-forcing the code offline, because the server was using a bad RNG.
Furthermore, PAKEs are of relatively limited utility; in almost every situation you could use a PAKE, there is a better, more battle-tested alternative. You will be much less likely to have complete authentication bypass in your system if you use mutual TLS rather than a PAKE.
If you have to use a PAKE, use a reviewed implementation of SPAKE2. Oh wait, there aren't any. Don't use a PAKE.
He also mentions checking the origin/referrer header. I would strongly recommend against this strategy; as he says, it doesn't work everywhere. Specifically, regular form submissions will not include the origin header in most browsers, and the referrer header is simply not reliable.
More importantly, multiple strategies for CSRF protection is bad. You need to fall back on tokens anyway, so the "check origin first" method is basically just an extra bypass for attackers to abuse. Two checks in this case are significantly worse than one, because if either is broken you are insecure.
There are users who could literally (yes, literally) have their lives saved by using whatsapp rather than SMS. But because of this article, they won't. You don't have to take my word for that. Zeynep works with those people, and will tell you the same thing.
There are a number of competing goals when developing software that "the whole world can/will use". And it seems obvious to me that getting the whole world to use a secure, encrypted messenger like Signal (now, Whatsapp) is a noble goal. The obvious competing goal is federation, and the fact that we've failed at improving federated services (e-mail being the best/most important example) is a problem.
Ultimately, Moxie's arguments here hold a lot of sway for me. I think it sucks that constantly-improving services are impossible to address in a federated way, and he's not really offering a solution to that. But instead he presents arguments I hadn't thought about much, which is that perhaps non-federated services can be dramatically better than federated services in the short-term. And in the long term, perhaps we'll move back to federated services; right now, the cost of changing services/ecosystems is very low. So we don't need to be as 'doom-and-gloom' about the fact that Signal does not achieve all the competing goals, because it achieves a number of extremely important goals right now, and we can work on the other goals in the future.
> This type of score card drastically simplifies the problem domain, and leads one to question what the tradeoffs are when installing an application from the list. While the advocacy of privacy based communication is something we love to see reach a mainstream audience, we believe the scorecard misses many considerations and metrics that are critical to the discussion.
To quote myself:
> The EFF score card is an embarrassment which is essentially equivalent to one of those "comparison table of our competitors" on a SaaS website. That's a good analogy for it, because it uses the same questionable metrics and even more questionable ranking system that one of those tables would use. The score card gives Signal the same ranking as Cryptocat - that's an instant negative result for its usefulness.