What 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).
Chrome 56 will mark HTTP pages with password fields as non-secure
191–200 of 419 posts
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#192What should be done for routers and printers that are accessed by their IP address?
I suppose it really depends on your threat model. I think most offices will be fine with the warning. However, you could configure each device to only respond to the trusted IP address of a HTTPS proxy which at least lowers the attack surface for snooping.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#193Earlier quoted context omitted.
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…
Honestly, why would you do any of those things, now that installing a certificate takes 5 minutes and is free, with Let's Encrypt? I know that you're just exploring solutions because it's interesting, but all those things take longer than Let's Encrypt.
It may take way more than 5 minutes.
My experience with let's encrypt so far:
- the name of their tool was changed form "letsencrypt" to "certbot", breaking my cronjob
- for daemons that try to access the cert/key as non-privileged users, additional fiddling with permissions is necessary, which may even be overwritten on cert update if done incorrectly
- when the certs are renewed, daemons need to reload them. This means that ideally, you need to detect when a renewal actually happens (as opposed to an attempt), keep an up-to-date list of all daemons that use the certs and possibly completely restart them, dropping all existing connections (some daemons just don't support a live reload)
I'm not saying these problems are unsolvable, but may take way more than 5 minutes and I, for one, opted to renew my startcom certificate for another 3 years instead.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#194Earlier quoted context omitted.
> 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…
> You're being pretty irresponsible if you aren't using SSL for passwords. So you're gonna tell me the owner of this site is irresponsible because it has a page with a password field that is not using SSL? http://www.w3schools.com/html/tryit.asp?filename=tryhtml_inp... How can you make any claim without having any idea what (if anything) the password is protecting?
I don't see why you (or w3schools) would object to a warning being shown on that page. It's put forward as an example, it shouldn't be treated as real and something requiring security, so showing a generic warning confirming it's not secure is perfectly harmless and even expected
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#195Firefox 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.
Kinda like how your antivirus tells you about how the formidable threats it saved your ass from today? 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. How long ago did they announce that? I think just a couple months? They should have announced this much sooner. It's going to hit me hard…
>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.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#196I'm in an A/B test group where all pages are marked either green 'Secure' or red 'Not Secure', password or not.
I like it.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#197Countdown until a JS extension that takes a normal field and uses • characters to make it look like a password field without tripping Chrome's detector...
Then another countdown until normal input fields over HTTP are marked as insecure by Chrome.
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#198Not a Chrome user, but this is a great feature, and is at least moving things in the right direction. Really they should go farther though. The UI treatment is almost un-noticable, even if they went with the "red triangle" version. How about a red-background interstitial page or a modal with a clear "Get Me Out Of Here" and "I Know What I'm Doing" choice for the user?
And for all those "small businesses" that are going to get affected by this? It's hard to muster up much sympathy at this point. It's 2017, and you're still horsing around with vanilla http?
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#199Earlier quoted context omitted.
I know I guess I just have to vent some frustration. Time to move on I guess. Does anyone have good hosting suggestions for a web app that has a 1GB database and a few thousand active users? I can only afford ~10-20 EUR a month on shared hosting atm.
If you have control of your nameservers you can use cloudflare's free TLS offering and keep your current webhost.
What about actually solving the problem instead of tricking the user into believing their data is encrypted while being transferred to you?
Re: Chrome 56 will mark HTTP pages with password fields as non-secure
#200Earlier quoted context omitted.
Can we just ban inputs being manipulated on input? It's really annoying for custom implemented types like phone numbers that do the '(___) ___-____'. Half the time it seems they break if you mess up.
I'd be in favor of banning input manipulation but adding custom fields like phone which would accept regex formatters.
Browsers already support that. Good look convincing managers/clients/designers that they're sufficient on their own though.
The real problem is UI. Most of these plugins are changing the UI of forms to something that looks fancier (and more consistent) than the defaults.