Open Bug 966754 Opened 6 years ago Updated 4 years ago

Disable HTTP plaintext basic auth (and possibly other schemes)

Categories

(Firefox :: Security, enhancement)

enhancement
Not set

Tracking

()

UNCONFIRMED

People

(Reporter: mmn, Unassigned)

Details

There should be an option in about:config to disable plaintext when using HTTP basic auth, so at least some kind of DIGEST or maybe even SASL can be forced from the client-side.

Right now the authentication process _may_ still use plaintext with no configuration option to disable it.
1a) Enter a URL with authentication credentials, like http://abc:123@server.example/
1b) Enter a URL that requires HTTP authentication, like http://server.example/ and be presented with a dialog box asking for username and password.
2. Be unsure whether my password '123' will be sent in cleartext or using some safer method is used.


This is something of course most users wouldn't realise the purpose with, but when developing and using HTTP built-in authentication methods it would be neat for more security oriented people to be able to avoid ever having to risk sending a password in plaintext.

Add-ons could be written to control these properties and thus increase security against accidental password leakage.
The client can't force an authorization scheme in HTTP, the server specifies what it wants with a 401 + WWW-Authenticate header.

I'm dubious about the value of having a pref. It would have to be off by default (since it would otherwise break a bunch of sites using insecure auth), which means this would would only benefit a tiny number of users.
(In reply to Justin Dolske [:Dolske] from comment #1)
> The client can't force an authorization scheme in HTTP, the server specifies
> what it wants with a 401 + WWW-Authenticate header.

Yes, but (as it seems you understood but I'll clarify for others) this proposal would make it so that the client aborts authentication if the security level is unsatisfactory.

Perhaps this is more of a social problem than a technical one. I shouldn't use logins and passwords against sites I do not already know and trust to be well-configured (i.e. send secure WWW-Authenticate headers).

> I'm dubious about the value of having a pref. It would have to be off by
> default (since it would otherwise break a bunch of sites using insecure
> auth), which means this would would only benefit a tiny number of users.

I understand that it would only benefit a tiny number of users, so maybe this would be best suited as a plugin? Just like HTTPS Anywhere and such are good for security, but only benefit a tiny number of users who choose to activate such a feature.

Thanks for your comment, it always helps to shed light from a different perspective! Maybe this can be written off as a WONTFIX?
If folks like me want a less trusting client, a plugin that hijacks the address bar's URL and does these tests on its own would be the way to go.
You need to log in before you can comment on or make changes to this bug.