
Login Forms Over HTTPS, Please - _jomo
https://hacks.mozilla.org/2016/01/login-forms-over-https-please/
======
_jomo
> _If you’re submitting your login form over HTTPS, that’s good, but it’s not
> enough. You have to_ deliver* the form over HTTPS too.*

I'm glad they mentioned it. Too many people think their sites are secure if
logged in sessions use https and everything else is http.

Their example is that an attacker could insert JavaScript to steal the
password, however they could just as well change the form target from https to
http which is even less noticeable.

There's also a more detailed post [0] with reasons and explanations. You can
enable this setting in Firefox 44+ by setting
`security.insecure_password.ui.enabled` to true.

0: [https://blog.mozilla.org/tanvi/2016/01/28/no-more-
passwords-...](https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-
over-http-please/)

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

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

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

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

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

There are still parts of the world where caching proxies are used to conserve
limited transit bandwidth; CDNs don't solve that.

------
osolo
I wish they outlined a plan to push this icon out to Stable. Even better the
plan should call for the browser to eventually refuse to submit forms with
password fields unless HTTPS was used for both loading the form and submitting
it.

I think that developers who are still using HTTP with passwords either don't
understand the implications (and a tiny icon won't help), don't care, or don't
have "management buy-in" to spend the time to fix it. Having the browser force
best security practices will benefit them and everyone using their websites.

~~~
jakub_g
Browser should display a scary warning popup when submitting form to http
(either always, or maybe at least when there is input type=password in a
form). This would be annoying enough to get management buy-in to implement
https, if someone still maintains the app - better than a tiny icon.

Breaking stuff is a last resort, nuclear option. There are many forgotten, old
web apps that would totally stop working and people would switch to another,
less secure browser as a result.

~~~
nandhp
They used to -- see
[http://www.kentlaw.edu/faculty/rwarner/classes/legalaspects/...](http://www.kentlaw.edu/faculty/rwarner/classes/legalaspects/digital_signatures/VeriSign%20OnSite%20for%20Secure%20Server%20IDs.htm)
(§2.4, about half-way down) and [http://labs.ft.com/2014/05/do-we-really-need-
to-hide-the-url...](http://labs.ft.com/2014/05/do-we-really-need-to-hide-the-
url/)

But it was removed in later versions of Netscape and Internet Explorer,
because everyone turned it off as soon as they made their first search engine
query.

~~~
jakub_g
I remember that, though honestly internet was a bit different 15 years ago -
it was in (almost)-pre-HTTPS, pre-public-WiFi, pre-Snowden times. It's time to
progress now that the realities and technical capabilities changed.

Today there should not be "do not display this anymore" checkbox.

------
bluetech
I 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 "Kaspersky Labs" is injecting its domain
_into the CSP itself_ ).

~~~
tomschlick
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?

~~~
mcpherrinm
[https://getsentry.com/](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](https://github.com/getsentry/sentry/pull/2154)

------
jordanlev
I don't understand the distinction between the login form and every other page
of the site. If someone is logged in and then back to normal http, someone can
just grab the _cookie_ and pretend to be that person already-logged-in.

I suppose if one uses the same password for every account they have then
knowing their password is more harmful than just having access to 1 site...
but other than that it seems like a distinction without a difference.

~~~
throwaway7767
> If someone is logged in and then back to normal http, someone can just grab
> the cookie and pretend to be that person already-logged-in.

If the cookie is set through HTTPS, the browser won't send it when loading
HTTP resources. So the cookie won't be exposed that way.

We should still be using HTTPS for all traffic in 2016.

~~~
oxplot
If a website only uses HTTPS for login, then it has to set a cookie for HTTP
as well, otherwise how will the user navigate the site after login? From top
of my head, you can implement this by associating the randomly generated
session ID that you assign to all visitors, with the login ID.

Regardless, what jordanlev said still applies. The session can be hijacked.

~~~
jordanlev
Exactly! What is the purpose of being "logged in" if when you then go to
browse the rest of the site you are no longer actually "logged in" (because
the secure HTTPS cookie isn't being sent on those insecure http: pages).

------
rosalinekarr
The best solution is just to make everything use HTTPS. Using HTTPS for all
traffic also helps to obfuscate which connections are the important ones.

Certain unnamed three letter organizations and nation states have the
computing power to crack HTTPS encryption if they really want to, but using
that power is expensive. Making sure all your traffic is encrypted makes it a
lot harder for potential snoops to decide which traffic is worth spending the
time and money decrypting and which isn't.

By using strong encryption for everything, even just reading wikipedia pages,
you're doing everyone a favor by helping to make user privacy that much harder
to violate.

~~~
sbierwagen

      Certain unnamed three letter organizations and nation 
      states have the computing power to crack HTTPS encryption 
      if they really want to
    

Some ciphers and key lengths are vulnerable, but I do not believe it to be
true to say that the NSA can "crack HTTPS", outside of a suborned-CA MITM
attack, which isn't at all deniable or subtle.

------
ams6110
I don't think many people pay much attention to the address bar, let alone a
little lock icon with a red line through it.

If they want to get serious about it, they should just disable http support
and require https for all actions. Or throw up a big in-your-face warning on
http pages, not just make a small change to an obscure icon that nobody really
understands.

~~~
r3bl
> If they want to get serious about it, they should just disable http support
> and require https for all actions. Or throw up a big in-your-face warning on
> http pages, not just make a small change to an obscure icon that nobody
> really understands.

Even though I agree with you, I think that it's still a little bit too early
for that. My prediction is that the browsers are going to start experimenting
with this near the end of 2016 and that it'll become a part of stable versions
of browsers somewhere in 2017.

------
herge
There are too many security holes and corner cases to serve _any_
authenticated page over http. It's better to have your login page be served
over https, but if you use authentication cookies, any MITM can easily pick
them up from the following http pages and do what they want (for as long as
the cookie is valid).

And that's beside a whole rake of issues from having http and https on the
same domain. It's just easier to have https everywhere.

~~~
chimeracoder
> 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!

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

~~~
geostyx
I have found Caddy ([https://caddyserver.com](https://caddyserver.com)) really
helpful in this regard. By default it grabs a Let's Encrypt cert and serves
your site over HTTPS (oh and it handles renewals too.) Caddy + LetsEncrypt =
easy https everywhere :D

------
mstade
Prominent? A crossed over lock icon in the address bar? Try again.

A prominent warning would be something ridiculous, like a full page cover
saying "THIS PLACE IS NOT SECURE – HERE BE DRAGONS!" or something. Browser
vendors should do more of this for egregious errors on the publisher's side.
Unless users complain loudly that stuff is uncomfortable and broken and scary
and what not, you can write articles like this every day of the week and
publishers still won't do anything about it, and the only users to care will
be the geeks who understand what the damn icon means in the first place.

~~~
_jomo
Would be an interesting thing to do as a network operator - doing MITM to
alert people about the dangers of HTTP.

~~~
y4mi
they're already doing it - for different reasons though

there have been reports of replaced adds on unrelated pages with banners from
the ISP and similar things

------
sugarfactory
What I don't understand about authentication over HTTPS is, though, why not
making login a part of the protocol? Wouldn't it be much better to
authenticate a user with a public key of the user like in SSH, instead of
password authentication over the public key of the server? It'd be more
resistant to attacks such as MITM or stealing the private key of the server.
If a user can register a password on a website, why does it have to be a
password rather than a public key? The only hindrance is the fact that the
protocol doesn't support it.

I have no idea why this easy change hasn't been made in the protocol.

~~~
colanderman
Check out the abandoned Mozilla Persona, and the SRP protocol.

[https://developer.mozilla.org/en-
US/Persona](https://developer.mozilla.org/en-US/Persona)
[http://srp.stanford.edu/whatisit.html](http://srp.stanford.edu/whatisit.html)

------
bjornsing
The 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](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

~~~
ultramancool
You can also submit your site for inclusion on the HSTS preload lists:

[https://hstspreload.appspot.com/](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.

~~~
bjornsing
Thanks, that's good to know. :)

------
mhw
I'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 a site I'm more likely to
continue to ignore it as I've been conditioned into assuming it's a false
indicator.

At the same time, for normal web users I can see how such a warning could be
helpful. But it seems normal editions of Firefox won't have this enabled by
default.

Or are my development practices unusual in some way?

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

------
thedz
Hiding mixed content warnings (like Chrome did last year
[http://arstechnica.com/information-
technology/2015/10/chrome...](http://arstechnica.com/information-
technology/2015/10/chrome-finally-kills-off-the-http-https-mixed-content-
warning/)) would probably also really help some sites with SSL everywhere.

On sites that allow users to embed things like images (forums, comments, etc),
in order to avoid mixed content warnings or interstitial confirmation dialogs,
you either have to pipe everything through an SSL proxy, or severely limit the
types of things users can embed.

------
irascible
I'm not writing login code personally but this sounds like something
fundamentally broken in the web and asking devs to fix it case by case is a
complete copout. If a browser can detect this shit, why can't it fucking proxy
it or do something clever to mitigate it automatically instead of putting up
stupid hyroglyphs and expecting to shame developers into duplicating a bunch
of work case by case and thereby probably getting it wrong in many cases? ..
like.. ff detects insecure login form.. Browser DON'T FUCKING SEND CLEARTEXT
PASSWORD (instead sending some encrypted bs to firefox grand central station,
where it is securely forwarded through a secure backchannel? Maybe it has to
talk to the isp directly who has to inject the password back into your
process, and they charge u extra tax for securing your shit.. and then..
gasp.. problem solved and not every aspiring developer needs to become a
cryptographer.

Passwords are stupid. The internet is broken. My Spyware infested machine and
browser knows all my passwords anyway.

Note to any techies reading this.. fix this problem. Here is your killer app.
Disrupt this shit.

------
lern_too_spel
Facebook had this problem for _years_ , even after they started hiring
industry veterans who would know better ([https://www.sslshopper.com/article-
how-to-make-a-secure-logi...](https://www.sslshopper.com/article-how-to-make-
a-secure-login-form-with-ssl.html)). Amateur hour lasted for so long that just
thinking of their codebase makes me ill.

------
mosburger
I don't know why sites don't just use HTTPS for everydamnedthing. It's 2016.
SSL is not _that_ computationally expensive and it's just easier to develop an
entire site that way anyway (rather than making some pages secure and other
non-secure). Just redirect everything to https and forget about it.

~~~
codazoda
I work on a site with a long history. I recently created a benchmark and found
that I could make around 500 synchronous HTTP requests to our infrastructure
per second (essentially localhost calls). If I switch my benchmark to HTTPS I
can only make about 5.

That's a big difference. I'm a developer, not a hardware guy, so I don't know
what causes the slowdown for us. I assume it's the actual setup and teardown
of the HTTPS connection. That is a fairly significant difference when I want
to use API's via HTTP/HTTPS and I need to make a lot of calls quickly.

My point is that HTTPS still seems to be 100x more computationally expensive
than HTTP.

------
mholt
Injecting JS into the page with the form isn't my main concern, even -- it's
changing the form POST action to their own server rather than the one I think
I'm logging into. That's much harder to detect and block without encryption.

Plaintext HTTP is scary stuff these days.

------
corndoge
Login forms over HTTPS, everyone. This time we'll finally fix web security.

This time we'll be safe.

------
dh997
Wow, this is still even a thing.

The form, all its js assets and form api endpoint all have to be secured. And
https for everything that contains code. Deploying SRI for web pages over
https is also another layer of defense against js tampering.

Also, sending passwords across the wire in any reversible manner is really
more dangerous than is necessary. Passwords/passphrases could be salted hashed
by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before
being sent to the backend for constant-time comparison... it just takes a
little more prudence and effort, but it's absolutely doable.

~~~
jstanley
> Passwords/passphrases could be salted hashed by the browser in JavaScript
> using a PBKDF similar to scrypt or bcrypt, before being sent to the backend
> for constant-time comparison... it just takes a little more prudence and
> effort, but it's absolutely doable.

This is not safe! Now an attacker just needs to intercept the hashed password
and replay that, and he gets to login without knowing what the password is.

Use https. And don't do client-side hashing, it's no improvement.

~~~
megous
This doesn't make any sense to me. If attacker can intercept connections I'd
rather he get the hash than the plaintext password. At least then actual
password is still not compromised, which is good, given how _many_ people
share passwords accross services. If he can tamper with connections, there's
nothing that can be done anyway.

It would be very nice if there was a feature in web browser that allowed
_user_ to opt in to something like this:

When there's a password input on a website: 1] automatically take website's
domain concatenate it to plaintext password 2] generate a secure hash from 1]
3] Derive some reasonably portable text password (20-30 characters) from 2] 4]
Make it so that original web page never has access to user's plaintext
password 5] Submit result of 3]

Downsides:

1] Stupid websites enforcing password rules other than length (can be worked
around mostly transparently). 2] Extra stupid websites limiting password
length. (requires user interaction and configurable exceptions for such
websites) 3] Can't login with browsers that don't implement this.

This would be very nice for people who share passwords between services. Also
would make web service data leaks less valuable to attackers. User would not
depend on service password handling quality and/or operator's morality.

I use different passwords for each and every service. But many people can't be
bothered or don't get the risks of password sharing, so it would be at least
some help to them.

~~~
dh997
Exactly. That's the risk to mitigate. Here's scrypt for js using emscripten on
actual scrypt C source... the site has to provide and adjust/migrate the three
factors over time to ensure a sane amount of cpu/memory is used:
[https://github.com/tonyg/js-scrypt](https://github.com/tonyg/js-scrypt)

For real-world, practicality's sake, the client-side of an app would contain
the PBKDF or some AA code, as opposed to the traditional, slightly-riskier
"let the server handle all of it"-approach... the server still has final say
on authentication and authorization, just move some of it into client-side js.
There's really not much impact on FE development considering most FEs and BEs
are codeveloped these days anyhow.

Btw, for web devs Two-factor auth is cheap and easy to do, Google
Authenticator OTP has open source libs and requires no calls to Google to
work.

------
alexc05
I love this, but would prefer they didn't re-use the "invalid certificate"
icon.

As a devs, we use self signed certificates for building our products and we
have trained QA to ignore the HTTPS with a slash through it as an error that
is acceptable in dev.

(And ourselves for that matter)

That makes this one easy to miss.

My preference would be a browser-level warning bar to roll out over the page.
Like the one used in 'this plugin is not installed'

This is a huge error and its much harder to miss that way.

------
tbrock
A little red padlock? It's a start... but why not refuse to load the page if
it has a form tag but no https. That's how you solve this.

------
kinofcain
This is how the Tunisian government scraped the Facebook passwords of Tunisian
internet users in 2011:

[http://www.theatlantic.com/technology/archive/2011/01/the-
in...](http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-
of-how-facebook-responded-to-tunisian-hacks/70044/)

------
Sarkie
I've used this Chrome Extension for years.

[https://chrome.google.com/webstore/detail/unsecure-login-
not...](https://chrome.google.com/webstore/detail/unsecure-login-
notifier/ledomejmbiemgdfiekmhoheabhonihmi?utm_source=chrome-app-launcher-info-
dialog)

It seems we are finally getting it built in, as it should be!?

------
r1ch
How about "Ads over HTTPS, please"? Can't upgrade our sites if our ad revenue
drops through the floor.

~~~
aback
Hmm. When technology basically took away musicians's ability to sell digital
music files, the world pretty much said, "figure out a new way to sell music."

So, "figure out a new way to advertise." Welcome to disruption.

------
Dylan16807
Now if only I could convince firefox (and chrome) that this asterisk-input
text field is _not a login form_.

------
hackaflocka
So, if I understand it correctly, HTTPS costs developers money (annual rent
for renting an SSL Cert).

Google too is about to start shaming non-HTTPS connections (according to a
recent article).

I've heard about the free one-year Cert. Is there any way to do HTTPS all in-
house (permanently), without resorting to an external agency?

~~~
jakobdabo
[https://letsencrypt.org/](https://letsencrypt.org/)

~~~
hackaflocka
Thanks.

------
Animats
Now this is the use of HTTPS that matters. This should get a major browser
warning. It's far more important than "HTTPS Everywhere", which is mostly
security theater.

------
yeukhon
The icon is nice addition, but a much better option is an animated icon. A
heartbeat / pulse kind of alert icon for insecure web page.

------
Gratsby
This is not a good thing. The expense of SSL certificates is not negligible,
and it is not justified. The protocol is easily compromised.

Much like email, https needs to go away in favor of a solution that
incorporates a modern mindset.

------
known
Legalize insider trading; It'll fix/solve HFT;

------
insulanus
Verb in Sentence, Please.

