Open about:config page in firefox. Create a new Integer key (right-click->New->Integer): network.http.phishy-userpass-length with value 255.

You can configure Firefox to ignore passwords entered on other sobdomains of the crrent domain.

To do so open the advanced configuration page about:config and change the value

signon.includeOtherSubdomainsInLookup = false

If hides all passwords on any subdomain that does not match the domain it was originally entered.

So, my question is how can Firefox know that login page address?

It doesn't, actually.

Your ISP uses a technology known as a Captive Portal. Captive portals work by "somehow" hijacking the browser's HTTP request and re-directing it to the login portal.

This "somehow" can be achieved in different ways, for example

• HTTP Redirect
• ICMP Redirect
• DNS Hijacking

Your browser, in turn, tries to detect this "hijacking" by trying to retrieve a well-known web page and checking whether the response they get back is the response they are expecting or something else. Here are some examples of pages that such "hijacking detection systems" use:

• http://captive.apple.com/ (Apple)
• http://msftconnecttest.com/ (Microsoft)
• http://connectivitycheck.gstatic.com/generate_204 (Google)
• http://clients3.google.com/generate_204 (Android pre-6.0)
• http://detectportal.firefox.com/success.txt (Firefox)

The Google one gives a hint as to how it works: The webserver will respond with an HTTP 204 No Content status code. A captive portal, however, will return content (otherwise it would be useless) and therefore never answer with a 204 status code. Most likely, it will use a 307 Temporary Redirect to tell the browser to fetch a different URI (the URI of the captive portal login page).

The other ones use a small document with well-known content instead (e.g. Apple's simply contains the word "Success").

The hijacking detection doesn't have to be performed by the browser, actually. Most modern devices will automatically run this "captive portal hijacking detection" automatically whenever they connect to an open WiFi and automatically pop up a dialog allowing you to go to the captive portal, without you having to explicitly open up your browser and visit some web page.

The reason for this is that in the modern Internet world, a browser is not necessarily the first app a user would be trying to use the Internet with. It could be the Facebook client, WhatsApp, or email client, for example.

Note that I used the term "hijacking" deliberately. These techniques are actually basically performing a Man-in-the-Middle attack. (The difference being that a "real" attacker would try to redirect you to a website that looks exactly like the one you wanted to visit and trick you into entering your username and password on the fake website.) Hence, these techniques only work as long as you are trying to visit an "insecure" website, i.e. a website that does not use SSL/TLS (i.e. no https://), does not use HTTP Strict Transport Security (HSTS), and the likes.

This is starting to become a problem, because more and more websites are only accessible through HTTPS (TLS). Modern browsers remember whether a website supports HTTPS and will use the HTTPS version, regardless of what you enter in the URI bar. Techniques such as HSTS ensure that browsers will always use the encrypted version of a website. Newer versions of the HTTP protocol such as HTTP/2 and HTTP/3 don't strictly require encryption, but all major browser vendors have decided to only implement them for HTTPS connections.

If you try to visit Facebook or SuperUser, for example, your browser will automatically use an encrypted, authenticated connection, and when the captive portal tries to redirect the browser to the login page, the browser will detect this manipulation and throw an error. Normally, this is exactly what you want, but in this case, it will prevent you from logging into the captive portal and thus from using the Internet.

If you ever run into problems where you are connected to the WiFi, but your apps show errors or load indefinitely, the reason is almost certainly that for some reason you are not logged into the captive portal. Maybe you didn't see the notification popup, maybe the detection failed, there can be many reasons.

In this case, you can solve the problem by visiting a website that you know is "insecure", i.e. doesn't use HSTS, SSL/TLS, or HTTP/2 (the standard specifies both HTTP and HTTPS, but browser vendors have decided that they will support only HTTPS for HTTP/2 going forward). The above-mentioned URIs should do the trick, but there is actually a website which some nice people have put up that serves exactly this purpose, and whose URI is easy to memorize: http://neverssl.com/.

NeverSSL does exactly what its name suggests: it is simply a completely useless website whose sole purpose is to never use SSL/TLS, HSTS, HTTP/2, QUIC or anything other than un-encrypted, un-authenticated, insecure, plain HTTP/1.1, so that the captive portal can intercept the request and redirect to its login page.

It is indeed not possible to pass the username and password via query parameters in standard HTTP auth. Instead, you use a special URL format, like this: http://username:[email protected]/ -- this sends the credentials in the standard HTTP "Authorization" header.

It's possible that whoever you were speaking to was thinking of a custom module or code that looked at the query parameters and verified the credentials. This isn't standard HTTP auth, though, it's an application-specific thing.

If you're a developer with 3 minutes to spare, this is how to do it without installing another add-on.

1. On the login page, Inspect Element the username and password fields and take note of their name (or id, if no name is given) attributes. For example on Khan Academy, that would be identifier for the username and password for the password.

2. Inspect Element somewhere on the page. Find a small div or so, that's easiest.

3. Right click the element in your inspector and choose Edit As HTML.

4. Add the following HTML:

   <form method=post>
     <input name=identifier>
     <input type=password name=password>
     <input type=submit>
   </form>
   

   Replace the names (identifier and password) with the names from step #1. Note that you should not replace type=password, only the name=password field!

5. Enter your credentials on the page in this form and hit submit. Firefox will now prompt you to save the credentials. The website will probably burp up an error or ignore the request or something, but we don't care about that.

Why does this work? Some sites deliberately do something funny to prevent you saving the password (the browser's remember password feature is often seen as insecure); other sites just have a funny form mangled beyond recognition for Firefox. Adding this simple form makes Firefox detect it and when you enter your credentials, it will prompt you to save them.

Now on the login page, as long as the fields actually have name attributes at all I guess (and it probably needs to be wrapped in a <form> too, I don't know), Firefox will typically recognize the fields and be able to fill them for you.

Alternatively, it might simply be that the website has autocomplete=off set on the field. You can remove this as follows:

1. Launch "Tools > Web Developer > Inspector" and hover your cursor over the form
2. When the form element is highlighted, look for the attribute that says autocomplete='off' (You may have to scroll up and look for the form element in the Inspector tab)
3. Double click the attribute and change off to on
4. Firefox should now ask you to save your username and password