What should be done for routers and printers that are accessed by their IP address?
[deleted]
Chrome 56 will mark HTTP pages with password fields as non-secure
281–290 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#282Earlier quoted context omitted.
I think the point is more like an HR administrator who opens a web page, containing an employee's details. They need to update the employee's home phone number, but their password manager dumps the HR administrator's password into the "Set new password" field, which is therefore overwritten.
So don't put the "set new password" field right in the employee's details page, use an extra page or popup for that.
Our application is still maintained, so we can find workarounds or restructure the form to use an extra popup (to the detriment of usability). But i'm sure many applications won't be updated, and as a result of this change, data will be silently corrupted when they are used. The browser has knowingly broken compatibility with the web application.
This is a Torvalds "don't break userspace" moment.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#283Stupid question: Is the warning going to show up for localhost i.e. using chrome to see the local dev version of your website?
see chrome://flags to disable security warnings on localhost -- great for development
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...
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#284Earlier quoted context omitted.
With free ways to encrypt web coming out, you really have no excuse to not use https for login forms. People should be informed.
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 go…
>Many small companies are going have an impact thanks to this.
if those small companies aren't offering secure logins to their users, they should be impacted. that's the whole point. You shouldn't get to risk your user's security just be being small. Implementing SSL is not difficult or expensive, and the prevelance of password re-use means that a small company with an unsecured login is causing a risk all around the net.
we've been educating people about SSL for years. if they haven't figured it out yet, it's time to start shaming them.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#285Earlier quoted context omitted.
If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality. If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that passwo…
> If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. You don't think it was adding anything in the example page I just linked you to?
Only a false sense of security.
Since the page is loaded as plain text, it can also be altered by anyone with network access between the server and the user. Javascript can be very trivially injected that simply sends each keydown event to the server, giving away the user's "hidden" password.
So even if the code you wrote doesn't ever send the password input to the server, that doesn't mean code hasn't been injected by some third party by the time it gets to your customer/user.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#286It's great that Google wants to move more sites to https, and I'm in support of this, but it also creates challenges for security vendors such as myself. Currently DNSFilter and others Man in the Middle traffic destined for sites our customers have decided to block. This works great for http, but not https, as certificate warnings are presented. The standard work around is arguably less secure: adding a third-party C…
Removing insecure HTTP altogether is the road Google is taking. That should make this a non-issue.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#287Firefox has started to do this recently and it's been fantastically informative and helpful. It's the one new browser feature I never really considered wanting/needing before, that's really stood out to me as being incredibly valuable since I've started to see the warnings pop up.
I can see it is a great way to warn users.
Also I love FF.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#288What happens if the page is insecure, but the attacker places an iframe in the page with HTTPS url, which then tricks the user into sending their credentials (unsuspecting users will think they are logging into the site).
I'm not sure that really fit what is changing here... If the forum is submitted it's going over https even if the iframe is on an http page. If an attacker has the ability to add code (iframe or other) to your site you've already lost.
that's exactly my point. I am hoping/assuming chrome would notify the user about this as well.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#289Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"
Well I'm fairly certain it will go like this for me. Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "we'll need to setup encryption. It will need to be FIPS-140 certified or it's not secure" Developer - "But you didn't care when there was no encryption" Pm - "We don't need to certify plaintext, that should be obvious. You need to learn more about security".
where do you work
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#290Earlier quoted context omitted.
With free ways to encrypt web coming out, you really have no excuse to not use https for login forms. People should be informed.
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 go…
This maybe my own rule of thumb but i believe that companies that serves sensetive forms over http also save the password in plain text.
They should be a shamed.