I'm a fan of this dialogue style. Particularly for showing the history/motivations/context of a design or situation. Kerberos is what first introduced me to it http://web.mit.edu/kerberos/dialogue.html
Thought this was going to be about password cracking, but instead turned out to be an interesting take on MITM vectors which bypass the password and piggyback on an existing session.
I would think that anyone with that level of access to compromise the channel would likely be able to just compromise the server itself?
Not so. The NSA smiley [1] showed that the smartest of attackers (or maybe the chinese are, but that's besides the point) are still (or were still, as of ~5 years ago) relying on passive MITM. It's far easier to exploit a passive vulnerability for a long time - Active exploits leave traces, give clues as to who you are. Passive exploits often leave the user without any idea that they are being snooped.
Mitm is often pretty easy, e.g. just arp spoof someone on the same network as you. Though if your target is on a different network, maybe not so simple. There's definitely a point where it probably makes more sense to try to attack the server than a well secured client; in general, hackers will aim for the weakest link (which I doubt will be your cookies not being channel bound)
> I would think that anyone with that level of access to compromise the channel would likely be able to just compromise the server itself?
That point is often brought up when discussing security, though personally I think non-maximally-effective attacks are also worth discussing - an attacker may have a reason to refrain from using full powers available for him. For instance, compromising the server immediately may lead to detection and subsequent mitigation of the attack, whereas just tapping a channel may remain undetected for long and let the attacker gather intelligence, select a particular target or perform some other, unexpected attack.
> I will find or compromise a shady certificate authority and get my own certificate for your domain name
Woah there, I don't think this is a realistic expectation of an attacker.
However, the author is right in that it is much easier to attack the endpoints. Users install every piece of software on the planet, and the Firefox/Chrome user storage directory is in clear access for all programs. There are also many remote code execution vulnerabilities in the wild that could be used to query a database server or steal keys.
I thought the same. I think at this point we've graduated from "there's already a metasploit / other open source code for it" to "it's probably possible, if you are fairly determined but not necessarily the NSA". There's probably a few CAs with lax security procedures, just given how many there are... but hacking one is a much bigger endeavor than SSL stripping.
Except that the phone itself is increasingly the target. A compromised phone renders such "second-factor" idents moot.
I say "second-factor" in quotes because I don't really consider the code-to-the-phone a second factor. It's just another password. A proper second factor would be a token, a physical object or at least something that cannot be transmitted/intercepted.
I'm running into this problem when doing PCI audits. PCI demands two-factor for some things (internal, non-customers) but specifies the 'something you know, something you have, and something you are' approach. Since biometrics are out in most situations, that leaves passwords+tokens as a practical mandate under PCI. Code-to-the-phone schemes don't qualify.
It's also expensive...the vast majority of users aren't going to buy a U2F key and carry it around. They just won't. 2-way OOB authentication does protect against phishing when combined with other information, such as IP geolocation. For example, the message could say "if you are not in [city from which login is coming], do not reply to this message".
Simple OOB authentication is much better than nothing, and I agree with you that most users aren't going to buy an U2F key unless it's subsidized and/or required by a service (look at Github - they're running a $5 U2F YubiKey promotion right now).
But still, there's no way to make this really secure for the average user. IP geolocation is easily tricked - a scammer just needs a large enough botnet and he'll be able to pick an IP address in the same city for the majority of victims.
Hm I think they changed the offer, because when I went through a week 1/2 ago I got two for $15 (including shipping). Ah yep...
>While supplies last, GitHub users can purchase special edition U2F Security Keys for $5 plus shipping and handling (regular price $18; 5,000 special edition keys available).
After the special keys are gone, all GitHub users are eligible for a 20% discount on U2F-certified YubiKeys, for a limited time.
Everyone will soon be using hardware key signing devices for identification and authorization as these keys are gonna basically be free within a couple of years. We're also moving towards self-authentication with public key crypto.
