Now if only I could convince firefox (and chrome) that this asterisk-input text field is not a login form.
Login Forms Over HTTPS, Please
101–110 of 121 posts
Re: Login Forms Over HTTPS, Please
#102The most secure approach is to serve everything over HTTPS AND redirect HTTP to HTTPS WITH "Strict-Transport-Security" header [1]. Even this is not perfect, but it's the best approach available AFAIK. 1. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
You can also submit your site for inclusion on the HSTS preload lists: https://hstspreload.appspot.com/ This fixes the remaining hole of the first visit. However, one warning, if you like privacy, you should turn off HSTS or clear it on browser close at least. It's effectively a giant supercookie and it provides little security benefit over checking URLs for SSL yourself.
Thanks, that's good to know. :)
Re: Login Forms Over HTTPS, Please
#103I'm puzzled. As a developer the sites I work on are (mostly) going to be hosted on my local machine. I usually don't bother with all the effort to set up SSL certificates for my development web server unless I've got an SSL-specific issue to investigate. Is this feature disabled for sites that are local? If not I'd expect I would just come to ignore it quite quickly. Then when I then look at the production version of…
The comments indicate that the icon will never be displayed on `localhost`.
I'm not sure what the situation is like for websites hosted on a LAN or using something like zero-conf, but I wouldn't be surprised if they do display the icon in those scenarios.
Re: Login Forms Over HTTPS, Please
#104Earlier quoted context omitted.
Yes, it's disturbing how many sites still do this. Most of the big shopping sites like amazon.com, ebay, Target, WalMart are http until you log in. Was also until recently very common on credit card sites, though all of mine are all https now.
This is because most people are browsing and not buying, so the caching advantages of unsecured catalogue pages is likely quite large. At least for most of those the login is a separate protected page rather than a https iframe.
Yes but the "login" link, the "add to cart" link, etc. is all served over http so could be replaced by a MITM.
Re: Login Forms Over HTTPS, Please
#105Earlier quoted context omitted.
> It's just easier to have https everywhere. For what it's worth, this was not true ten (or maybe even five) years ago. I'd say it's true today, for most websites, but it's worth keeping in mind that it's a relatively recent phenomenon that HTTPS is now pretty easy to set up, use, and maintain. That wasn't always the case!
Five years ago was 2010. Other than Let's Encrypt, AFAIK, there hasn't been exactly leaps and bounds in terms of making https easier, at least for self-managed servers. It's still buy a certificate and set it up in nginx/apache/your favourite load balancer/etc.
SNI and IPv6 are two pretty big ones since the limited number of IPv4 addresses limited the practicality of having one IP for each SSL site.
Re: Login Forms Over HTTPS, Please
#106Earlier quoted context omitted.
For too long popular a lot of popular gambling sites such as betfair and skybet have done this. I think betfair now is all https, but I'm not sure of skybet (and I can't be checking while at work).
Betfair is finally using all https. Their security was terrible because once you logged in, the site went back to http again. This meant that anyone on the same network could grab your cookies and take over your account...
Isn't betfair the one where the password reset email was sent to the email in a hidden input field which you could change yourself....?
Re: Login Forms Over HTTPS, Please
#107Earlier quoted context omitted.
This is because most people are browsing and not buying, so the caching advantages of unsecured catalogue pages is likely quite large. At least for most of those the login is a separate protected page rather than a https iframe.
Uhh, what caching advantage are you talking about? Everything that can be served cached over HTTP can also be served cached over HTTPS. Unless you are talking about a caching proxy outside of the website control. In that case, they aren't needed, CDNs solved that problem in a much better way.
"Everything that can be served cached over HTTP can also be served cached over HTTPS. "
Only if you're taking about a browser cache. Any other cache couldn't intercept the data and cache it without alerting the browser (unless you mess around with installing SSL certs).
Re: Login Forms Over HTTPS, Please
#108Earlier quoted context omitted.
> Use https. And don't do client-side hashing, it's no improvement. Well, it's an improvement if your users are reusing their passwords. Then multiple different sites will have different hashes sent. But that's all besides the point, we should've been using zero knowledge proofs for authentication since the beginning.
With HTTPS, multiple different sites will have different "hashes" sent anyway, so no, it's not an improvement over just good ol' HTTPS.
Well, sure. But then you have to worry about how well the website is storing your passwords. Meh, password managers are the way to go to be honest.
Re: Login Forms Over HTTPS, Please
#109Earlier quoted context omitted.
As I understand it, if not everything is HTTPS, the attacker could just inject JavaScript that changes the page to the login page when the user clicks "Log in". That way, they can still record the password.
Yes, it's disturbing how many sites still do this. Most of the big shopping sites like amazon.com, ebay, Target, WalMart are http until you log in. Was also until recently very common on credit card sites, though all of mine are all https now.
Amazon cares much less about your security than about the fact that tiny increases in latency decrease conversion dramatically.
Re: Login Forms Over HTTPS, Please
#110I have recently deployed Content Security Policy (CSP) on a website. When I first looked at violation reports, my jaw dropped. The amount of malware (rouge extensions, toolbars, viruses, ...) that is blocked is staggering. If you really want to help your (clueless) users, never ever serve a login, registration or credit card form without CSP. It really helps - at least until the malware catches on (I already see "Kas…
Is there a pre-built tool to capture and manage CSP violation reports? I believe its mainly just a POST request with some JSON right?
https://getsentry.com/ added support for CSP a few months ago, but I haven't tried it out yet. https://github.com/getsentry/sentry/pull/2154