[rlidwka]

It doesn't change anything. As some people used to say, "security is binary; you either are secure or you are not".

While it's useful for phishing pages to be interactive, it's not strictly necessary:

----

"Your paypal account is locked, because we suspect it to be hacked. To unlock it, please call our tech support (phone number 1-234-56789) and tell them your paypal password to prove your identity (and CVV of all the credit cards pretty please)."

[neotek]

It absolutely changes things, there's a marked difference in severity between encouraging someone to call a number or respond in some other way to written instructions, and capturing their login details on a page they've been trained to trust (i.e., https with a green lock.)

I'm certainly not saying there's no issue here - your example perfectly demonstrates a realistic and dangerous use case - I'm merely pointing out that omitting such an important aspect of the vulnerability in the repo readme is disingenuous and materially changes the severity of the issue. To be honest, the omission actually smacks a little of clickbait.

[mSparks]

it's a proof of concept. I don't see how it changes anything. once you've got the browser displaying https://site you control pretending to be something else.

fixing everything else is trivial.

[jrochkind1]

> As some people used to say, "security is binary; you either are secure or you are not".

I think anyone that used to say that was just wrong. "We" (software community in general) have a much more sophisticated understanding of security than we used to, and realization that absolute security is virtually impossible. Security is always a continuum of risk management.

Bruce Schneier writes:

> Security is a trade-off. This is something I have written about extensively, and is a notion critical to understanding the psychology of security. There's no such thing as absolute security, and any gain in security always involves some sort of trade-off.

He's not writing specifically about digital security in that quote, but since he's foremost an expert on digital security, it's safe to say his opinions on security in general apply to digital security too.

It's a good essay, worth reading.

https://www.schneier.com/essays/archives/2008/01/the_psychol...

Here's another Schneier quote about digital specifically:

> That is why security experts aren't surprised by the Sony story. We know people who do penetration testing for a living—real, no-holds-barred attacks that mimic a full-on assault by a dogged, expert attacker—and we know that the expert always gets in. Against a sufficiently skilled, funded and motivated attacker, all networks are vulnerable. But good security makes many kinds of attack harder, costlier and riskier. Against attackers who aren't sufficiently skilled, good security may protect you completely.

https://www.schneier.com/essays/archives/2014/12/sony_made_i...

[kentonv]

> As some people used to say, "security is binary; you either are secure or you are not".

Disregarding all other context: I disagree strongly with this statement. Practical security is about risk management, and is never binary unless you've proven the absence of bugs (and backdoors) through your whole stack down to the transistors (unlikely). The practical exploitability of any particular bug is certainly relevant.

[orf]

> Your paypal account is locked, because we suspect it to be hacked. To unlock it, please call our tech support...

This is why it makes it a lot less severe.

[tptacek]

Isn't this a little like suggesting that it's a vulnerability that someone can have a large <img> tag with a GIF of Facebook's login page on it?

[rlidwka]

If facebook allows you to put an arbitrarily large img tag onto any of the pages under its domain (so internal navigation could be hidden under it), then yes it is a valid attack vector.

[ajross]

> As some people used to say, "security is binary; you either are secure or you are not".

I'm sorry, which people used to say that? I'm not aware of any serious security professionals who hold that opinion. "Security" is and has always been a complicated spectrum of interactions and requirements.

[rlidwka]

I don't remember the exact quote, and might have used one out of place.

I am thinking about it in binary terms, because it helps to prevent security through obscurity trap many seem to fall in.

My point is: the fact that a particular bug has security impart seems pretty binary. And dismissing one because "hey nobody will think of/work hard enough/have enough money/etc. to make use of it" isn't a very bright idea.

See 3rd party content under a legitimate url? The system is insecure. Period.

[schoen]

One thing you might be thinking of is "there should be one mode, and it should be secure".

http://iang.org/ssl/h3_there_is_only_one_mode_and_it_is_secu...

This isn't exactly the same as what you said, but I think it's an argument in favor of your point of view.

Another analogous thing is that academic cryptographers will regard an algorithm or protocol as broken if an adversary can gain a significant advantage (probability of distinguishing things that are supposed to be indistinguishable, reduction in work factor, etc.), even if the resulting work factor to mount the attack is still enormous. For example, if there were an attack that could break AES in 2¹⁰⁰ operations, AES would be considered broken even though we believe there is no one who can perform 2¹⁰⁰ operations, because it no longer provides the designed or advertised security margin.

[mahouse]

Security is not binary at all. Your computer is not 100% secure as you should know yet you are still plugging it into the Internet. Aren't you?