Live data from Hacker News

Bypassing Browser Security Warnings with Pseudo Password Fields

troyhunt.com

121–127 of 127 posts

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#121

Earlier quoted context omitted.

The key thing to realize here is that the browser is the "user agent": it is supposed to represent the interests of the user. Now users have pretty diverse interests, so browsers don't always get this entirely right, which is one reason it's important to have a variety of browsers so users can pick one that does represent their interests. What's happening in this case is that the site is doing something that pretty m…

> the browser is the "user agent": it is supposed to represent the interests of the user > it's important to have a variety of browsers so users can pick one that does represent their interests First of all, I'm now terrified of Mozilla/Firefox, because this comment reflects the idea that browsers should be developed as independent ethical entities that represent different groups, in the way special interest groups l…

> because this comment reflects the idea that browsers should be developed as independent ethical entities that represent different groups

I'm not sure where "ethical" came into that.

Some users want to have features that allow them to read websites in their preferred fonts. Other users don't care about fonts, but _really_ care about the colors and want high contrast. Still others want to have strong privacy safeguards (think Tor), while a fourth set care about privacy a bit less than that, and a fifth set don't care about privacy at all. These diverse needs might best be served by multiple different browsers that focus on different aspects of the user experience.

I see no reason why a browser that explicitly tries to make the web more usable for people who are red/green colorblind, say, should be a problem, though it seems to me that you do....

> it's dangerous to put the onus of security on everyone but the user

No one is suggesting that. However the reality is that there are maybe at most double-digit numbers of different browsers, maybe hundreds of millions of websites, if you're very generous, and billions of users. You ideally want to enforce security at chokepoints, which is why the browsers do most of the lifting here, then websites, then users.

There have been tons of user education campaigns in the history of the internet. To some extent they've even worked.

> The browser should not become a political toy. It should be simply a tool

Sure, and no one suggested it should be a "political toy". But maybe one user wants a flathead screwdriver and another wants a phillips head. And a third one wants a hammer, or hex wrench.

> This could have been trivially handled by simply asking users how much concern they want to have over their security

Been done, via surveys. The answer is "a lot". And yes, we could just say that if they care then they should be constantly vigilant. But constant vigilance is something people are really bad at (on a hardware level!), compared to computers. So any time we can design systems that don't require constant vigilance from people we probably should. I would go so far as to claim that requiring constant vigilance from people when we don't have to, and then blaming or punishing them when they cannot comply, is simply unethical.

> or providing some mechanism for organizations to easily transition into technology changes at a pace that works for them

This is why browsers have been cooperating at creating things like Lets Encrypt, precisely to provide such a mechanism. The question of timeframes is a complicated one, of course.

> Browsers are completely at fault for handling security so poorly in the first place.

No argument there. This is something browsers have been trying to do better.

> Now it's clear that a mentality of moral superiority and special interests is the cause.

I think you're reading things into what I said that were simply not there.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#122

Earlier quoted context omitted.

You didn't just talk about the debate. You stated as a fact that many vaccines have improper testing or substances. If you state something as a fact, you should be prepared to back it up.

> You stated as a fact You're putting words in my mouth. What I said was "...without what many would consider..." I'm still taking about the debate itself and you're trying to make this a binary debate about vaccination.

You stated toxicity as completely objective. (And you had better mean "toxic at the doses given", because anything is toxic in large-enough quantity.)

> What I said was "...without what many would consider..."

That's still calling them correct about the vaccines not meeting those standards. There are a lot of claims about vaccine testing that are objectively false. It's not that their standards are higher, it's that they falsely believe vaccines undergo less testing than they actually do.

I don't want this to be a binary debate. I want you to quantify 'many' and provide actual evidence of anything.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#123

Earlier quoted context omitted.

I'm assuming you're talking about consumer VoIP; in the corporate world, Cisco (and presumably others) do a crapload of VoIP office phones.

I also haven't seen an office phone in ages, it's just all mobiles around here.

You are almost certainly an exception. The next time you are out in public, just look around. VoIP phones are everywhere.

Hell, I have a Cisco VoIP phone on my desk in my home office, tied into $work's phone system.

(I actually have three VoIP phones here at home, but I'm a network engineer for an ISP/CLEC.)

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#124

Earlier quoted context omitted.

SIP... doesn't seem like the greatest protocol. Maybe I'm tainted because I've only really dealt with it in the context of the Microsoft IM/telephony platforms (renamed constantly, but always essentially the same), but it appears to be incredibly brittle complicated. On anything less than a local LAN, messages get dropped or mangled or timed out all the time, and that trashes connections, or puts sessions into unreco…

I guess you can argue about whether it's the greatest protocol, but the problems you describe most certainly are not procotol problems, but rather broken implementations.

The protocol problems are due to the text-based format and a bizarre desire to make said text format "human friendly". It inherits the stupidity from HTTP (line folding, comments in headers) and adds its own fun. The authors actually suggest that the "intent" of the message be followed in case of errors. It's terrible. The packet issues are due to the strange use of UDP with mandatory TCP switching. Needless complexity.

Oh and these aren't theoretical. Two big, widely deployed implementations cannot even agree on how headers end, and will read the same message differently. This can be exploited when a network does header processing. Imagine adding a "x-accountid" header, and removing any existing ones - if interpretation differ on what constitutes a header, an attacker can slip fake headers in. Not entirely dissimilar to browser exploits that let script include a header with a newline in the value, letting scripts maliciously set headers they shouldn't be allowed to.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#125

Earlier quoted context omitted.

I guess you can argue about whether it's the greatest protocol, but the problems you describe most certainly are not procotol problems, but rather broken implementations.

The protocol problems are due to the text-based format and a bizarre desire to make said text format "human friendly". It inherits the stupidity from HTTP (line folding, comments in headers) and adds its own fun. The authors actually suggest that the "intent" of the message be followed in case of errors. It's terrible. The packet issues are due to the strange use of UDP with mandatory TCP switching. Needless complexi…

Well, yeah, I certainly didn't mean to say that SIP is a great protocol, it is indeed quite terrible--but still in practice if things don't work, that's usually a result of at least one party not following the spec (which is not really surprising , given all the pointless complexity ... but then that's still not really an excuse to not implement SIP when you are claiming that you do).

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#126

Earlier quoted context omitted.

The protocol problems are due to the text-based format and a bizarre desire to make said text format "human friendly". It inherits the stupidity from HTTP (line folding, comments in headers) and adds its own fun. The authors actually suggest that the "intent" of the message be followed in case of errors. It's terrible. The packet issues are due to the strange use of UDP with mandatory TCP switching. Needless complexi…

Well, yeah, I certainly didn't mean to say that SIP is a great protocol, it is indeed quite terrible--but still in practice if things don't work, that's usually a result of at least one party not following the spec (which is not really surprising , given all the pointless complexity ... but then that's still not really an excuse to not implement SIP when you are claiming that you do).

Practically, it is not possible to implement the spec in an interoperable way. Existing implementations are mutually incompatible. Hence the need for config flags per "trunk". What one system requires, another will reject. Sad but true.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#127

Earlier quoted context omitted.

Well, yeah, I certainly didn't mean to say that SIP is a great protocol, it is indeed quite terrible--but still in practice if things don't work, that's usually a result of at least one party not following the spec (which is not really surprising , given all the pointless complexity ... but then that's still not really an excuse to not implement SIP when you are claiming that you do).

Practically, it is not possible to implement the spec in an interoperable way. Existing implementations are mutually incompatible. Hence the need for config flags per "trunk". What one system requires, another will reject. Sad but true.

Well, yes. But still, more often than not, when I encounter interoperability problems, if both sides actually did what the spec says, there wouldn't be a problem. SIP itself is quite sad, but in my experience many implementations are even worse than the spec.
Post reply on HN