399703 - Password manager offers to store logins with empty passwords

Status: RESOLVED WONTFIX

(Toolkit :: Password Manager, defect)

Description

[Fred Wenzel [:wenzel]]

When I log into one of my embedded linux boxes' web interface, it needs a username but an empty password (HTTP auth).

When I enter it, Minefield asks me if I want to store this "password". I click "remember" but nothing happens (the blue stripe doesn't disappear either).

The next time I come back, I have to enter my credentials over again: Nothing was saved.

Expected behavior: I'd like it to store the username and empty password. Or, second best option, don't ask me if I want to store it in the first place ;)

Comment 1

[Justin Dolske [:Dolske]]

I'm inclined to WONTFIX this, we already don't save form-based logins when there's no password.

There is a bug here, though, in that we shouldn't offer to save the login in this case. :-)

Comment 2

[Fred Wenzel [:wenzel]]

Well, as I said: Second best option, still a bug :)

On the other hand, since there obviously *is* a login happening (judging by the fact that a HTTP auth window pops up) I think the pwd mgr should always be able to store what was entered, no matter what it was. This would be consistent.

Admittedly: It's a rare use case, anyway. But sounds to me like it may be an easy fix.

Comment 3

[Isaac]

This worked in 2.0.0.11 (saved the login).  What value is there in NOT saving the login?  Was useful to me, and seems like a regression.

Comment 4

[[e-mail]]

I can confirm that this problem still exists in ff3.0rc1. I think empty passwords should be saved too, as it was made in ff2.0. 

e.g. TWiki has users with empty passwords by default. 

Comment 5

[m]

I can confirm, the problem exist in ff3.0rc3 too.

It is really annoying that every time, when I want to open http://localhost/phpMyAdmin/ I have to type 'root' every time...

Empty password is still a password, so I think Firefox should save empty password either.

Comment 7

[Nick]

I had submitted bug 442141 which is a duplicate of this one.  I searched before submitting, but obviously not carefully enough.  Sorry about that.

At the very least, if FF3 isn't going to remember the password, it shouldn't offer to.  The existing behavior is misleading.

Comment 9

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

Comment 10

[:Gavin Sharp [email: [e-mail]]]

What about form-based logins?

Comment 11

[Justin Dolske [:Dolske]]

Form based logins already ignore empty password fields... When _onFormSubmit() is looking for the password fields, it winds up calling _getPasswordFields() with skipEmptyFields == true.

Comment 12

[Justin Dolske [:Dolske]]

Pushed changeset b9181db84ccb.

Comment 17

[Fred Wenzel [:wenzel]]

According to bug 499938, this regressed. I still think a username with empty PW should be saved rather than special-cased, but do as you please.

Comment 18

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The changeset pushed for this bug only eliminates saving empty passwords for forms, not for protocol authentication.  Thus the reported issue (that the incorrect behavior exists on HTTP Auth) was never actually fixed.

Quoting from nsLoginManagerPrompter.js

LoginManagerPrompter
Implements interfaces for prompting the user to enter/save/change auth info.

nsIAuthPrompt: Used by SeaMonkey, Thunderbird, but not Firefox.
nsIAuthPrompt2: Is invoked by a channel for protocol-based authentication (eg HTTP Authenticate, FTP login).
nsILoginManagerPrompter: Used by Login Manager for saving/changing logins found in HTML forms.

By fixing nsLoginManagerPrompter.js, it was assured that no prompts would be issued for empty passwords in HTML forms, but the alternative code prompt for nsIAuthPrompt2 still throws prompts (see starting at line 437).  nsIAuthPrompt probably does the same thing (I didn't check).

I am willing to write a patch either way we decide to go on this, but I would strongly suggest that we revert the changes made previously on this bug and allow an empty password.  Even though it's called password manager, it's really "credentials manager" and a username is still a valid credential.  If it's absolutely anathema to allow that, I will write the identical checks into the prompts for the nsIAuthPrompt and nsIAuthPrompt2 sections, but I would urge that taking the alternative course suggested originally in this bug (and in 499938, as well as many of the other dupes).  It might not be wise security practice on the part of whatever is asking for authentication, but IMO that's not really our concern.hints at it.

Comment 19

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

OK, sorry for the spam, 80% of what I said above is wrong.  My apologies for the time wasted reading above.  The patch was only checked in on trunk, not on the 1.9.1 branch, so I was looking at the wrong files.

499938 isn't a regression, it's invalid, but I do believe that the current behavior is still wrong (that we should save empty passwords.)

Comment 20

[Justin Dolske [:Dolske]]

Back to WONTFIX, for the same reasons as before.