Chrome 56 will mark HTTP pages with password fields as non-secure (opens in new tab)

Firefox Release channel has been logging console errors for this for at least two years.

"Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen."

Looks like that url lost its final char [1]

I use DE, so I have been seeing these for a little while, but I think even in the stable channel you can toggle the security.insecure_password.ui.enabled param to true in about:config.

1: https://developer.mozilla.org/en-US/docs/Web/Security/Insecu...

> Now all my users are going to hear that my site is insecure, when nothing at all changed.

You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users.

If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do that, you're negligent and you should stop doing business with the public.

This is a huge red flag. If you really don't think SSL is important, it raises disturbing questions about your approach to security in general. Which other standard security practices have you ignored? Are you using strong hashing for passwords? Are you properly handling input to prevent SQL injection?

I am not a security expert, but as I understand it, passwords sent in the clear are vulnerable to being intercepted. Even if users of your site don't have much to worry about from those accounts being compromised (this may or may not be true), lots of people use the same password for more than one login, so their accounts on other sites could be compromised too.

That's definitely a significant security risk, even if it wasn't being explicitly labeled before now. It sucks for independent website operators like you, but I'd probably blame your hosting for making it difficult to secure your site rather than browser vendors for protecting their users.

> Now all my users are going to hear that my site is insecure, when nothing at all changed.

Correct, nothing has changed, it has always been insecure.

So what? It's the harsh reality of unsecure http.

Maybe your website has some important information and the user is just unaware of the dangers when entering his credentials on your website. Good for him, now firefox is warning him. He can choose to continue or not. Fortunately, if your website doesn't really hold any sensitive information then the user will go forward.

The market demand will naturally require that all shared hosts start offering some sort of free HTTPS as webmasters such as yourself will simply be required to migrate somewhere where $hosting + $HTTPS is cheaper. This means shared hosts may start integrating with services like Let's Encrypt to save costs.

In fact you could be proactive and announce to your shared host that for this reason you will be relocating. Let them know there will be a trend of other webmasters relocating for the same reason.

As more and more website features (passwords, geolocation) start requiring HTTPS by browsers we will naturally approach the point where HTTPS is free and ubiquitous, at which point everybody wins.

Also, you've had a one year notice that this was going to happen: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...

>Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" >Now all my users are going to hear that my site is insecure, when nothing at all changed.

I'm not sure you should be allowed to drive a webserver.

Yes. One of the positive aspects of this change is that it punishes the people who are either unable or unwilling to migrate to SSL.

>Now all my users are going to hear that my site is insecure, when nothing at all changed.

Nothing's changed: Your site really is insecure, it's just that now users know.

> How long ago did they announce that? I think just a couple months? They should have announced this much sooner.

A year ago.[1]

[1]: https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...

Move your site....

Your negligence pose security risk to your users, they should be warned.

Your site's server is just one node in the chain of nodes between your server and the browser. Any one of these nodes could be malicious and tamper with the data in either direction. In other words, this isn't about just your node, it's about all nodes.

It may not be an option for you, but you could consider using a free proxy service such as Cloudflare.

Shameless plug (since I work on Firebase) but if your site works on static hosting + BaaS, Firebase Hosting will give you free SSL + CDN support.

Your site IS INSECURE. Nothing at all changed because it was, and now the user can just see it.

In my country and probably a lot more, you'd be held legally responsible if by any means customer data would leak out. Be it stuff sent over a wire unencrypted, or an account with administrator access being compromised due to unencrypted password transfer.

I dare you to go to a hacker or security conference once, just for kicks. Connect to any wifi there, log in. See what happens.

Why do you have a password field on a http site?

A few solutions:

- Create a font such that every character shows up as a * and use it for a text input.

- make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div.

- implement the text box ground up from scratch using div's and JS, like google docs does.

- implement a HTTPS password field in an iframe and communicate with it over post messages.

> onKeyDown

Right-click paste from my password manager, and it doesn't work. Thanks.

---

This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.

That's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable.

Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.

> an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways.

For anyone who is wondering what these ways are, here are a couple:

1) Backspace is a crufty special case

2) What happens when someone highlights text in the input box and types over it?

+1 for using CloudFlare. I just deployed the front-end website for my new startup (https://elasticbyte.net) using Google Cloud Storage (like S3) and CloudFlare for custom SSL. CloudFlare also allows me utilize CNAME flattening, so the the root record for my domain simply points to c.storage.googleapis.com.

you can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low<sarcasm/>...

> I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site.

Interesting. Where are all these warnings when a CDN man in the middle attacks your connection? Or when google gets to access all the email communication of gmail users? Or when ad networks track you all around the web?

IIRC, type=password also prevents copying saved input to clipboard

My colleague used a custom web font where every glyph was replaced with a filled circle. Better browser compatibility, you know.

Although our reason was actually to do with password managers. At $DAYJOB we have a CRM/ERP system with lots of password fields for other entities (not the current cookie user). It's increasingly difficult to opt out of browser autofill, and LastPass in particular was corrupting password data in the system whenever forms were submitted.

I used this same hack for a XenForo add-on [1] and even got labeled as black hat.

[1] https://xenforo.com/community/threads/let-tls-wait-paid-dele...

Developer - "FIPS-140 has been compromised by the NSA. We don't want government spies in our servers."

where do you work

I don't even get to that badness: the browser needs to accept third-party cookies first. (I wonder what badness is behind all there.)

The correct answer is always "IE doesn't support it"

> SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works.

I keep hearing this, but failing to see it. Since OpenSSL's inception.

Go has it now, but their delay was their own internal SSL rework as well.

Do they also do it for IBAN?

I suspect PCI is okay with it so long as it is an unsecure page that posts to a secure one. Not that it's a great idea, but it would be encrypted in transit.

Edit: It appears PCI DSS V3.2 does ask that the form itself be on a secure page (section 4.1.g):

"for browser-based implementations: 'HTTPS' appears as the browser Universal Record Locator (URL) protocol, and Cardholder data is only requested if “HTTPS” appears as part of the URL."

PCI-DSS is okay if you put it in an HTTPS iframe. Many sites I've seen use that workaround.

> I'm assuming that public wifi has session-specific encryption keys.

That's false for open wifi networks. Remember Firesheep? Just fire it up at your local coffeeshop and off you go.

Even for more secure public wifi like WPA2, vast majority of coffeeshops still don't change the default router admin passwords so you can take over it easily and listen in on all the traffic.

Further, it's not hard for some rando to setup a safe-looking access point and get people to connect to it. Camp out near an office with a router, I'm sure you'd get plenty of hits.

There's no shortage of attack vectors with no warrants required.

> who is in a position to tap your connection such that this becomes a serious security concern?

When you use HTTP everything is sent in plain text. This means...

- Anyone on the same network as you can see all of your traffic. This includes company networks, coffee shop wifi, your house, the library; any place that has a WiFi network. Caveat: it's possible to use network isolation to hide your traffic but this is crazy rare to see and typically is done to isolate networks, not individual traffic.

- Your ISP can see and log everything sent over HTTP.

- Anyone at the router level that your traffic passes through. Your traffic makes a lot of hopes over various routers on the internet before making it to your final destination.

Overall it's a terrible idea for anything that needs to be sent securely.

Your assumption about public wifi is wrong. If you connect without a password, your traffic is sent in the clear and MITM attacks are trivial. If you don't want your password exposed to any hacker with an old Pringles can within a mile of your location, you need end to end crypto.

HTTPS isn't just about encryption either. It's about authentication and integrity as well.

Making sure the server you are talking to is the correct one, and making sure that nobody along the way injects ads, trackers, malware, or anything else.

Man, someone should really invent a way to make webpages respond to the dimensions and capabilities of the user's device.

If the page is loaded on a mobile device you'll get the mobile version anyway.

I'd be in favor of banning input manipulation but adding custom fields like phone which would accept regex formatters.

Where do you see the issue? Creating a certificate that no one else has to trust seems pretty easy already.

it's weird that the warnings aren't disabled by default on chrome for localhost: it's officially classed as a "secure origin"

https://www.chromium.org/Home/chromium-security/prefer-secur...

That's…actually quite smart, I wasn't aware of that.

Thanks -- this has solved an ongoing problem I was having with a couple of clients.

For example, I've given the WPA2 password to many people; and that can be used to snoop on it passively (there's no forward security).

Modems are anyways way more insecure due to the default password being admin or 123456, etc. And many are accessible from the public internet.

I think my modem got hacked due to that (I saw some login attempts a little before the DNS got changed causing Youtube to stop working).

So, now we have a single certificate on all routers? What happens if I take apart a router?

Or would every router get its own certificate? But then netgear would have to become its own CA.

And in either case DNS hijacking is a massive issue.

Now you're vulnerable to DNS hijacking.

wait, wait, wait, are you saying a "trusted ip address" out on the web? or requiring every office to set up their own https proxy? Cause a "trusted IP address" out on the web would just be insane... "Oh, let's just send my login to and give full access to my network to this third party/manufacturer."

How does removing HTTP solve the issue presented:

When actively interrupting an HTTPS connection as a network element, there is no way to provide information to the user about the reason for the interruption or steps the user could take to prevent the interruption.

This can be done with HTTP, where a filtering proxy could show a page 'our software thinks this page violates company policies, but click here to override or contact IT to fix', or see also captive portals.

Maybe the right answer is simply there's no reasonable way to handle this use case in a secure manner, but taking away an established use is a real issue.

that's exactly my point. I am hoping/assuming chrome would notify the user about this as well.

The majority of the big sites that people use (Google, GMail, Youtube, Facebook, Reddit, NYT, WaPo, etc.) are already being served using HTTPS. I think if a couple of HTTP sites an average user still browses start showing these warnings they will notice them. And what matters, the owners of those websites will notice them and will ask their "IT guy" hey "why our website is marked as insecure? I want a green lock like Gmail has".

Plenty of websites think they only have to secure app.example.com, while www.example.com can be left uncovered even though it serves www.example.com/login, because /login POSTs to the app. subdomain, and the session cookie is only set by and for the app. subdomain.

From a naive perspective, all requests passing private information are protected in such a scenario. But, of course, since the www. subdomain is uncovered, it can be MITMed and replaced with a phishing site. (A.K.A. a "spear-phishing" attack.)

This change somewhat fixes that scenario: the developer can no longer keep the /login route on the insecure www. subdomain; they'll have to serve that page securely (either by making www. secure, or, more likely—because it's lazier—just moving /login to the app. subdomain.)

Even though www. can still be MITMed to replace it with a phishing subdomain, that subdomain can no longer serve a login form itself. It would have to link to a "real" phishing FQDN (one the attacker controls enough to get a TLS cert for), at which point that domain can just be found and blacklisted by the browser vendors.

In a sense, it forces the attacker into the open, where the attacker themselves can be caught/blocked, rather than simply their attack being caught/blocked. (In other words, it forces MITM attackers into a situation more akin to current botnet malware-writers, where they must put up C&C infrastructure which can be traced back to them.)

Of course, this isn't nearly as good as just securing the www. subdomain; and it will force much more work (likely, doing said securing) on those who want to embed a login form directly on their www. subdomain's landing page. But, in the interim while we work on universalizing TLS, it will drastically decrease the value of spear-phishing attacks, just as spam filters drastically decrease the value of unsolicited bulk email ad campaigns.

> because you are sending your session cookie which is equivalent to your password

This is extremely different for most users that don't use password managers and/or unique passwords per site. As if your password is leaked. Maybe all your other sites are now leaked(with same pass) . The same can't be said of cookies.

thanks

It's already the case most of the time. If you submit via a plain form (without js), you get the (old) "This page is encrypted, but the information you submitted will be sent unencrypted" message. If you submit via an XMLHttpRequest, it should be blocked as Mixed Content.

google competes with the likes verizon, comcast and at&t, and the data google gathers on you is very valuable. why would they want to share that data with the line operators for free?

sorry to say, but https is not an altruistic move by google.

This is a long term, strategic decision.

Better security = Greater trust of the web = Higher adoption = More ads.

No different to them working on Google Fiber.

In addition to all the genuine "let's make the web better" reasons, comprehensive TLS prevents middleboxes from inspecting or tampering with traffic, which in turn allows the introduction of better protocols like SPDY and HTTP/2, which brings content to users faster and allows pages that contain more disparate/modular content, which makes web applications more capable (in addition to the added security), which makes it easier and more appealing to migrate away from locked-in platforms. (And that's just one of many lines of reasoning.)

I can think few.. Adware substituting their adsense ads for theirs, also isps messing with ads etc.

I work for google, and i had a fair amount of work on moving Ads to HTTPS (moved mobile app ads to https)

The work actually started quite a while back, but the overall ads industry and internet as a whole moves really really slow. Add the mobile ecosystem to the equation, and there is a bunch of issues.

The whole work is a combination of a bunch of things (in no chronological order): 1. Google pushed search ranking changes. 2. Google moved all of ads to HTTPS, and this took some time to make it happen. 3. Apple created ATS to make people think about it. 4. Apple wanted to enforce ATS for non-web content, had to back out. 5. Let's encrypt made access to certs free. 6. Big vendors joined.

Unfortunately, the world is slow when it comes to changes like these, but i am quite happy with the outcome so far.

edit: added context.

How early? Put a year on it. What should they have done, and when?

If Google hasn't threatened people that ranking will sink if they didn't migrate to HTTPS, Let's Encrypt wouldn't have been so popular despite the fact it's free due to the pseudointellecutal SEO "muh performance hit, muh redirect rules" meme

This is not the right way to educate people. This is a sort of like shaming someone in to doing something. Many small companies are going have an impact thanks to this.

There are many companies I have personally witnessed that use a direct IP to access web based solutions to their inhouse software, how are these people supposed to get a ssl cert.

We need to educate people, not shame them in to doing the things big google wants from them.