User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1) Hi, I was just playing around with a Linux+Firefox in a Windows Environment and accessing a IIS Webserver. Since my Linux box is not part of the Windows Domain, I had to authenticate with username and password over HTTP. Firefox opens the usual username/password dialog. Since I was afraid to reveal my password over plain unencrypted HTTP, I traced the HTTP traffic and saw, that the server is offering NTLM authentication with challenge and response, and that firefox is able to do that. Nice. Password not revealed. Great. But wait a second. If someone managed to do a man in the middle attack, e.g. with tools like ettercap, he could modify the HTTP 401 Unauthorized header and offer plaintext authentication instead of NTLM. Since the user does not have any chance to see which authentication is going on and just see the usual authentication dialog, the user would reveal the password in plaintext to the attacker. That's called a 'protocol downgrade attack'. So my proposal is: - give much more information in the password dialog. Tell the user whom and how we are authenticating. Mark in red if the authentication is vulnerable to sniffing or man in the middle. Mark in red if the password is not sent over HTTPS. - If the password is once used for a secure authentication method, do not use it for any weaker method without user reconfirmation. Any password in the password repository should have additional properties telling the minimum security level and whom to authenticate against. - Same with web form passwords. Pretty often it is difficult to see whether the form will be sent over HTTP or HTTPS and whom to. There should be some warning if the data in a password entry type field is sent unprotected, and the password repository should know for every password whether to send it over insecure connections or not (and maybe to whom, e.g. the required name in a SSL server certificate). regards Hadmut Reproducible: Always

Confirming. This would be good to do for 1.9 if we can....

showing the type of auth is bug 115500 I'm not sure this needs to be marked security-sensitive. this requires an active MITM attack and at that point you probably have worse problems.

Beltzner, this bug should be considered when redesigning the password manager. Removing security flag, due to MITM attack required.