
Bypassing Browser Security Warnings with Pseudo Password Fields - pgl
https://www.troyhunt.com/bypassing-browser-security-warnings-with-pseudo-password-fields/
======
StudentStuff
If only we had these kinds of strong warnings in the VOIP industry. Nearly
every provider barebacks the internet, throwing unencrypted signaling data
(phone number dialed, keys pressed during the call, codec to use) and call
media over the internet raw, just hoping that no one eavesdrops or alters
their data.

HIPPA compliance? Nah bruh, unencrypted UDP is just fine! PCI-DSS says we
can't take credit cards over this wholly insecure connection? Who cares! Just
don't let the auditor near our PBX.

Sadly, the HTTPS and IPv6 anti-vaxxer crowd is strong in the VOIP community,
if it isn't severely painful to the VOIP company themselves, they aren't going
to secure it. Not that they'd secure it properly anyway, even if their
livelihoods depended on it...

~~~
distances
What are VOIP systems used for these days? Private enthusiasts or some company
call centers? I've no idea, as I haven't seen one for at least half a decade
now -- even all conference calls are always over Skype or Hangouts.

~~~
StudentStuff
The largest VOIP companies in America today are the cable companies, ACN
(pyramid scheme with a few million VOIP customers), Vonage (a first mover)
then a few dozen minor players that are near the half million customer mark.
IMO its a big (but unsurprising) marketing failure.

VOIP as a product never really made it into the home, despite all its features
and enhancements. Instead, it is limited to the realm of businesses, where it
is in most hospitals, medical facilities, chain stores, call centers, and so
on.

~~~
Xylakant
All landline phone connections sold by Telekom in germany are VOIP, it's just
mostly hidden from the subscriber. The technology is doing perfectly fine.

~~~
metilda
VOIP and specifically SIP in its least secure form became the replacement for
old tandem circuits. Sadly, rather than pushing SIP hardware out to the
endpoints, most lamdline carriers chose to just provide twisted pair service.

VoLTE is as close as most consumers will get to proper VOIP service.

~~~
Tijdreiziger
Giving everyone SIP phones is expensive, and forcing your subscribers to
purchase SIP phones will ensure a number of them flee to the competition.
Putting the VOIP hardware in the modem makes much more sense, because you have
to provide that to your subscribers anyway.

~~~
Xylakant
I actually have my own Cisco Phone adapter to connect my old analog
phone/answering machine. I'd assume that a true SIP phone would work as well.
What's questionable is whether I could authenticate from a different network
than my home network.

I know, however, that both Vodafone and Telekom in Germany offer products that
allow connecting VOIP phones from anywhere to a virtual phone appliance.

~~~
Tijdreiziger
That's interesting. In the Netherlands, all the telcos (with the notable
exception of XS4ALL) lock down the modems and don't give you the settings and
logins to use your own equipment (although the Consumer and Market Authority
is still researching whether this is actually legal).

~~~
Xylakant
Locking the connection to a provided modem is not legal in Germany since
2016-08-01 by law (FTEG, replaced by FuAG in 2017) The provider is obliged to
hand you the required credentials to connect your own hardware, though getting
the actual required configuration may require some puzzle work, but most
providers give config examples for at least the most common hardware. My setup
for example consists of a draytek modem with unifi network hardware and above
mentioned Cisco phone adapter. I don’t even have a piece of Telekom-provided
hardware here. Took a bit of googling to get IPTv working, but other than that
it’s a perfectly stable and capable setup. Many people use Fritz boxes which
are a bit less capable but easier to set up.

------
saas_co_de
"I’ve been speaking with the owner about SSL before I invest in becoming a
member, but she’s been told by the dev of the platform (it’s a franchise
system called ShopCity.com) that SSL is more about Google’s monopolizing
visibility of content, and less to do with security"

This is an interesting observation of how Google's technical crusades often
align with its profit interests.

The main threat that HTTPS everywhere secures against is preventing your ISP
from analyzing your traffic in order to build and sell an advertising profile
on you.

Now, obviously that is something I don't want, so I am all for HTTPS
everywhere, but Google already has that profile, so for them HTTPS everywhere
is eliminating the competition.

~~~
throwaway2016a
> The main threat that HTTPS everywhere secures against is preventing your ISP
> from analyzing your traffic in order to build and sell an advertising
> profile on you.

That is not true. The main threat it protects against is MitM (man in the
middle attacks) that allow someone to redirect all traffic to a website
through their machine and thus see all the data including your password.

HTTPS when combined with root certificate trust is very effective at
preventing these kind of attacks. Without it, using any shared internet at all
(such as a company, school, or coffee shop) to log into any website or enter
your credit card would be trivially easy to hack.

Seriously, I can boot up Wireshark, go to my coffee shop and easily see every
non-HTTPS communication going over the network. IM messages, emails, and in
cases like this post suggests... passwords too.

Edit: As a side note... I do this all the time to reverse engineer the
wireless protocol for IOT devices since most of them do not use HTTPS yet. I
use it for personal use but it could be used for harm as well. For instance,
if the security cameras are IP cameras over HTTP I could probably intercept
the password and use it to remotely turn off the cameras.

~~~
peterwwillis
MitM is blown out of proportion. Afaik, only dns poisoning attacks will result
in MitM as effective as phishing or botnets, and poisoning can be mostly-
solved with better resolvers. No criminal anywhere cares about your password
going over the wire in a coffee shop.

~~~
zAy0LfpBZLC8mAC
Which is true exactly up to the point where some criminal decides it's an
attack worth automating, as with every other attack.

The one thing that reduces the likelihood of that happening is to minimize the
amount of credentials you could get your hands on using that attack.

------
atesti
Nice trick. Can it be used to stop password managers? Our system works over
HTTPS and saving the password to login is okay of course, password managers
are great and they must obey the user, not the page. But on sone pages of the
system one has to enter credentials for other systems using password fields.
Chrome always wants to remember these and prefills it with the login data to
our system. Can this be stopped? Maybe by using this font

~~~
scaryclam
Have you tried adding:

autocomplete="new-password"

to the field? This is supposed to stop Chrome autofilling the value

------
lwansbrough
No need for the JS, just change the font if the input isn't empty, right?

~~~
maweki
yeah. The :empty() pseudoclass should do the trick.

~~~
vilmosi
:empty is for elements with no children, not empty value.

~~~
uitgewis
You could potentially use the validation rules, and set a min length of 1.

~~~
KwanEsq
You'd need [required] instead of [minlength] for :valid to work. The other
option is :placeholder-shown, to style no-input normally, but it's newer and
not as supported.

~~~
vilmosi
I wonder if the good old input[value=""] would work. Probably not if you have
jQuery.

~~~
bzbarsky
No, because that matches on the HTML attribute (aka the defaultValue property
in JS), not on the current value of the input.

------
pgl
It's kind of clever, but also bloody stupid at the same time.

------
jarym
I'm kind of happy that developers responsible for this type of stuff get
exposed - if they can't get HTTPS then in my mind there's a high chance that
other parts of their setup are following weak security practices. Now I know
where NOT to signup!

------
deckar01
This hack is exactly what I needed 2 days ago while working on a browser-based
terminal app. My site will be secured with SSL/TLS, but I needed a way to make
a content-editable span mask input like a password field. I already
implemented it with a password input, but it doesn't wrap inline like a span
does. It will be much cleaner to just add a class that masks the font.

~~~
throwaway2016a
Most terminal apps I use when you type in a password area nothing shows at all
in the terminal (not even a mask). Though admittedly, that is not the best
user experience for providing feedback.

~~~
aaronmdjones
The terminal has a feature called "local echo".

When you type something, it goes to the application (almost always its stdin
file descriptor, but it can open /dev/tty and read that too).

When local echo is enabled, the terminal also prints what you type.

Applications that prompt for passwords simply (temporarily) disable local
echo.

------
throwaway2016a
Edit: Ignore this. It seems most of the posts I was talking about were either
deleted or edited. Keeping my original message here for completeness sake.

\---

The number of people saying that this is a clever workaround and agreeing with
the people putting in the bug reports is very disheartening to see on HN. If a
highly technical crowd such as HN can't get why HTTPS is important than what
hope does everyone else have?

Troy hunt is a security researcher. The examples of the bug reports and quotes
were meant to terrify and it worked on me. If I was a customer of any of these
examples I would be pissed. If you're not upset and/or frightened please for
everyone's sake take an infosec course or read up on the subject.

~~~
Ajedi32
> The number of people saying that this is a clever workaround and agreeing
> with the people putting in the bug reports is very disheartening to see on
> HN

Huh? I've been through this entire thread and I haven't seen anyone suggest
that this is acceptable behavior; even in the heavily-downvoted comments. It's
mostly just people laughing at the lengths this site went to to shoot itself
in the foot.

~~~
throwaway2016a
Wow... looking at it now I don't either. I don't know if they got flagged or
deleted or editor of what. One of the comments in particular I can see was
clearly edited to be more clear that they thought it was a bad idea.

------
jenscow
Surely it would be easier to just get a cert.

What's preventing these types from doing so?

~~~
gruez
What's easier for a dev: inserting a few lines of code, or getting access to
the production server, setting up letsencrypt (or getting a budget approval
for the $10/year certificate)?

~~~
robteix
Code is rarely the same as "inserting a few lines of code" though. They
presumably had to think about how to work around the problem, look for an
appropriate font, etc. All for the purpose of hiding a symptom of an
underlying problem.

~~~
kgbme
Yes, exactly - there's a framework in place, which allows for the bullchit. :/

------
leemike
Can someone give a precise idea about this entire subject?

~~~
Ajedi32
Huh? I don't understand your question.

------
peterwwillis
I just realized: This site was never over HTTPS. It was an HTTP site, and the
browser had a regression that broke the site's user functionality.

Troy Hunt is attempting to claim this is a _feature_ and not a bug, and that
their workaround is "being deceptive", when they _never claimed it was secure
to begin with_.

The browser is literally pushing an idealistic philosophy down websites'
throats and basically doing damage to businesses and brands without an attempt
to help them, and any attempts to simply keep old functionality are being
vilified as "anti-vaxers". This is not an honest narrative.

Yes, Oil and Gas International had an insecure site, and yes, their reaction
and demand to the browser vendor was inappropriate. But the point of it is
still valid: as a vendor, you don't embarrass and damage business reputations
in order to force them to comply with the way you would _like_ them to run
their sites.

Troy writes in the article that browser vendors are trying to use a "lever" to
"force organizations to go secure". I don't care who you are, it's wrong to
force anyone to do anything they don't want to do, and on your timeline
instead of theirs, and with absolutely no help given to them before this
deadline.

Imagine if Microsoft changed their OS to flag every single application as
"insecure" if it doesn't implement a new primitive, and they pushed this out
today. All of a sudden, you receive a barrage of calls from upset users. You
didn't know they were going to push that out (certainly Microsoft never sent
you an e-mail), and you now have to hit the ground running trying to figure
out how to add those primitives to your code, test them, and release them,
none of which could possibly happen immediately, and may take weeks of
development. Meanwhile, your reputation with your users is damaged, and users
themselves go through emotional stress and fear. And Microsoft's response?
"Too bad. You should have been secure already."

This is fucked up. And if Google does this knowing it's going to damage
businesses, they could face a class-action lawsuit.

The only way they get away with it is because they have the biggest market
share. If Chrome had a smaller user base, businesses would simply shut off
access to Chrome browsers and tell them their browsers were faulty and to
switch to IE. This is impressively tyrannical behavior for a software vendor,
and Google is indeed being a bully.

~~~
bzbarsky
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
much everyone who understands the issue agrees is harmful to users: having
them type their password into an insecure page. Browsers and security
professionals spent 10+ years trying to convince web sites to stop doing that.
Then browsers spent a few years telling websites that they will start warning
users about this behavior and giving specific timelines for when this would
happen. Then they started showing those warnings they promised they would
show.

To go back to your analogy, it's as if Microsoft had told developers for a
long time that some specific API is deprecated due to being "insecure". Then
they gave a timeline for the API being removed. Then they removed it. Can
there still be applications who didn't move away from that API? Sure. Is it
entirely Microsoft's fault that they are now getting lots of support calls?
That's a hard case to make. Note that this sort of deprecation is something
that Microsoft and Apple have in fact done.

> The only way they get away with it is because they have the biggest market
> share.

Firefox is showing the same warnings, no?

> businesses would simply shut off access to Chrome browsers and tell them
> their browsers were faulty

Sure, just like in the Microsoft case businesses tell their users to not
install the OS security update, etc. You're right that if Chrome and Firefox
had smaller marketshare businesses _could_ threaten to do this or actually do
this. But at that point it's not entirely clear who the real "bully" is... In
either case there's an exercise of market power to get your way against the
(possibly reasonable) objections of others.

Disclaimer: I work for Mozilla, on Firefox.

~~~
peterwwillis
> 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
lobby on behalf of specific people, ignoring the concerns of everyone else.

Second, it's dangerous to put the onus of security on everyone _but_ the user.
I'm sure you've seen the wall of sheep: it's more than just http passwords.
Users are stupid, and they get security wrong, and they need to be helped to
get it right. But one thing that won't help them is absolving them of any
thought whatsoever into investing in their own security.

Where this will end is a marketing campaign that sounds a lot like "Mozilla
Firefox: The Secure Browser". All they need to do is download your program and
just assume everything is fine. Which will of course be a lie, but one that
everyone will accept, because they want it to be true.

The browser should not become a political toy. It should be simply a tool, and
it should be up to those who wield that tool to decide how it is used. If I
make an axe, I don't come to your farm and tell you how to swing it.

This could have been trivially handled by simply asking users how much concern
they want to have over their security, or providing some mechanism for
organizations to easily transition into technology changes at a pace that
works for them. Instead it seems like browser makers are too fond of
themselves as white knights to provide reasonable compromises.

Browsers are completely at fault for handling security so poorly in the first
place. They continue to have the most asinine user experiences in the world
when it comes to understanding what is actually going on when a user browses
the web. They continue to support standards which can be easily subverted.
They continue to build hack after hack into something that was supposed to
just _navigate documents_ and is now an entire fucking application platform.
Browsers are a mess, and it's their designers that are at fault for that mess.
Now it's clear that a mentality of moral superiority and special interests is
the cause.

 _And while I 'm ranting_, what is wrong with browsers that they can't simply
build a working secure authentication framework into the protocol and back it
with a halfway usable UI? How is it a 20 year old tool used to access backend
servers has a more effective authentication and authorization system than the
most commonly used program in the entire world? It's not like this stuff was
some mystery that the poor lowly browser devs couldn't understand. We don't
need to be relying on shitty web forms to send plaintext passwords - we didn't
need to be doing that in the year 2000!!!! How the hell is it that this piece
of software, which is somehow more complex than my entire operating system,
can't seem to perform the basic functions i've been doing with other programs
for half my life? And yet have the balls to claim they're working in service
to the user?

You know what would have been great for the users? A secure protocol which
didn't degrade its own security. A URI convention that refuses to communicate
with insecure sites. A button that rejects all connections not destined for
the domain in the address bar, and functions that control the browser or
access to its data without the user expressly allowing it. _Simple things_
that could have actually completely ensured users' safety, without ridiculous
complicated kludges that only do half of what they're supposed to do. And
these should not be considered controversial - it's not like I'm suggesting
they implement security policies before they add buggy features to brand new
releases.

You are right, though. Browsers did take 10+ years to enforce a policy that is
as unnecessary as it is sudden. I'm sure users will thank the browser vendors
now for how much safer they are from black hat hackers in coffee shops. Oh,
wait - they are still insecure. It's just now they know it and are unhappy
about it, and other organizations can now capitalize on this.

~~~
bzbarsky
> 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.

------
kgbme
LOL, I love the guys filing that bug report with Mozilla... Had to have cost
some overtime for their network admins. xD

The way I see it, this - along with most of things - when you place the
mechanisms there, people will use them and abuse them.

20 years ago, a browser had 3 MB and today they're 30 and 60 MB large, with
_much_ better compression of the installer.

Why do we need this-and-that service integration within the browser, to
"follow trends" of the likes of Adobe, Microsoft?..

I don't think so. Cut it all out. Someone wants to watch a video: install a
codec. Their service uses different coding? Tough luck, get with the (popular,
useful) standard(s), or gtfo.

What the hell do I care about your corporate policy of "creating new jobs" and
"advancing development", all you're doing -anyway- is peddling your products.
In my browser. On my hardware, which I paid for, meh. Introducing 1000&1
vulnerabilities, where there should be none.

Right, wrong? Know what I mean?

~~~
gruez
>Someone wants to watch a video: install a codec. [...] Introducing 1000&1
vulnerabilities, where there should be none

I'd rather use a codec maintained and updated by Mozilla every 6 weeks than
some "community maintained" codec that I installed years ago and has to be
manually updated.

~~~
drdaeman
YMMV, but I'd rather prefer browser vendor to work on a browser, rather than
try to become an operating system, with its own libraries and update channels.

A web browser shouldn't normally bundle image decoders, audio or video codecs,
on-screen keyboards or printer and video card drivers.

Obvious exceptions apply, of course - e.g. if OS doesn't have built-in image
decoder for a specific format it totally makes sense to bundle one.

But this is really getting off-topic.

