Live data from Hacker News

Bypassing Browser Security Warnings with Pseudo Password Fields

troyhunt.com

111–120 of 127 posts

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#111
post #37

Earlier quoted context omitted.

I don't want my ISP to inject JavaScript to random pages or analyze my traffic. That should be downright illegal. They should be like water supply company: provide me damn clean water and get out of my way. Somehow the sewage company doesn't analyze my urine (I hope ) to figure out if I prefer spicy or sour food and get an extra buck from third parties, and somehow they're still in the business .

> I don't want my ISP to inject JavaScript to random pages or analyze my traffic. That should be downright illegal. They should be like water supply company: provide me damn clean water and get out of my way. I don't want my search engine to do that either. They should provide me damn accurate results and get out of my way. Unfortunately, whereas I have a choice of several good ISPs here (UK), I have a choice of prec…

I have been using DDG for several years now, and it works just fine. You of course are free to like Google better - to each for their tastes, but please do not claim there's no choice. There is choice, and you just happen to like Google better - fine, so live with Google then :)

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#112

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…

[deleted]

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#113
post #30

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 w…

^^ Keys pressed... Jesus Christ, that alone has fueled entire generations of criminals. :))

Could we ask you to please comment more substantively, like the guidelines ask?

https://news.ycombinator.com/newsguidelines.html

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#114
post #24

Earlier quoted context omitted.

Pretty sure that means people who refuse to deploy TLS & IPv6, even when their hardware & software stack fully supports it.

There are situations where you need IPv4 due to rate-limiting. So while my stack technically supports IPv6 I have no reason to migrate to it.

You've been downvoted because this shouldn't be true, but since no-one else has stepped up, I'll bite :).

It's perfectly possible to do IP-based rate-limiting in the IPv6 world, you just need to do it based on different prefixes, rather than full IPs.

As a specific example, my ISP -- as is quite usual -- hands out /48s. So in the same way that you can rate limit my entire NAT'd IPv4 connection with a single entry, you can rate limit my entire IPv6 connection with a single entry, by storing the prefix.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#115
post #37

Earlier quoted context omitted.

I don't want my ISP to inject JavaScript to random pages or analyze my traffic. That should be downright illegal. They should be like water supply company: provide me damn clean water and get out of my way. Somehow the sewage company doesn't analyze my urine (I hope ) to figure out if I prefer spicy or sour food and get an extra buck from third parties, and somehow they're still in the business .

> I don't want my ISP to inject JavaScript to random pages or analyze my traffic. I haven't seen a single reputable ISP do this anywhere. It would illegal. Is the US really such a third world nation that not even basic regulation like this exist?

Siblings have pointed out how very much it does happen, but if I may take issue with:

> Is the US really such a third world nation that not even basic regulation like this exist?

First, the US is by definition the First World (USSR et al. being second world, third being "everyone not allied with first two"). Second, we have somewhat different ideas about freedom that, often, lead to an extreme lack of regulation; the hope is that this gives more freedom and we'll work around abusive actors (yes, I know monopolies are an obvious weak point in the system).

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#116

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…

This isn't about pages that are just serving good old fashioned plain #content, it's about pages POSTing passwords. Hopefully there is no need to explain why that is bad. I agree with most of your post, but it's coming from an incorrect assumption.

It's not coming from an incorrect assumption.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#117

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…

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

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#118

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.

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.

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.

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#119

Earlier quoted context omitted.

> (b) a mistaken sense of principle of standing up to the perceived bulliness of Google, which, come to think of it, it's basically an application of (a) But Google has been bullying around with their behaviour. I don't think that's even debatable.

They have been bullying around, but their enforcement of HTTPS for forms with password inputs shouldn't count as one of their instances of bullying. It's something browser vendors should have implemented long ago, even before LetsEncrypt came along, because it is highly insecure and users should know about it.

> It's something browser vendors should have implemented long ago

Netscape Navigator did this (almost) 20 years ago.

EDIT: Link. http://www.kentlaw.edu/faculty/rwarner/classes/legalaspects/...

Re: Bypassing Browser Security Warnings with Pseudo Password Fields

#120
post #39
post #29

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…

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

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.

Post reply on HN