201620 - should not cache failed username & password attempts at basic http auth

Status: RESOLVED DUPLICATE of bug 137852

(Core :: Networking, defect)

Description

[Calum Mackay]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030410
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030410

[I'm sure this bug must have been logged before, but can't find anything suitable]

When simple password authentication is used to protect a web page, mozilla keeps
a cache of the password used, for use in future access to this page. Note that I
am not referring to the password manager's store, which is controllable.

It appears that mozilla caches the password even when the access fails, i.e. the
access gets a 401 unauthorised error. This is a problem, since the user cannot
recover from mistpying their password without restarting mozilla.

Additionally, on occasion a user wants to change the username they've previously
used, and this appears not to be possible either.

The browser ought not to cache failed attempts (ie those that get a 401 error
from the web server) and there should also be a way to "flush" the cache, so
that the username/password need to be re-entered. The latter might be an RFE,
but the former is a bug, I believe.

Reproducible: Always

Steps to Reproduce:
1.visit a page that uses wev server password authentication
2.deliberately enter the wrong password and receive the 401 error
3.visit the page again

Actual Results:  
get another 401 error

Expected Results:  
prompted again for password

Comment 1

[Calum Mackay]

Here's a test page:

http://www.cdmnet.org/~calum/securetest/

which was secured with an .htaccess file:

AuthUserFile /home/calum/lib/passwdtest
AuthGroupFile /dev/null
AuthName "test secure area"
AuthType Basic
<Limit GET>
require valid-user
</Limit>

The username and password for this page are: calum/testypass.

Note two things:

o If you get the password wrong, there is no way to ever get it right again,
without restarting mozilla. At least, no way I can discover.

o If I added another username/password pair, you are not able to switch between
them. Once one is entered correctly, there is no way to get re-prompted to enter
the other.

Comment 2

[Calum Mackay]

Please disregard the test in comment #1. Ironically, in this case mozilla does
seem to work as expected.

In other cases - and I'm searching for an accessible example - it doesn't. One
example I can see internally, is access to my router's config page...

Comment 3

[Calum Mackay]

The test in comment #1 is still useful for demonstrating this 2nd part of this
bug, namely that once you have entered a password correctly, there is no way to
force a re-prompting, so you can change to a different username, if you wanted.

Comment 4

[Jo Hermans]

According to bug 159045, this is a dupe of bug 55181.

But I haven't seen that the wrong password was cached. In my experience, a wrong
password will clear out the existing password in the cache, and force you to
enter a new one (with a blank dialog).

Comment 5

[Calum Mackay]

thanks for the dup info; will check.

The only time a password prompt appears is on 1st access, so there is no
password in the cache to be cleared. In summary: the password prompt appears
only once, regardless of whether you enter the correct password or not.

I agree this doesn't happen for all pasword-protected pages (e.g. my test one)
but it does happen in many cases. I've yet to find an external page that can
demonstrate this bug.

Comment 6

[Calum Mackay]

I agree that bug 55181 covers the 2nd part of this bug, in that there should be
a way to flush the basic http auth cache, so that users may change login.

I don't see anything there about my main concern, the browser caching *failed*
auth attempts, which I don't believe should be happening at all, so I've
restricted this bug to that issue.

Obviously, a fix for bug 55181 would greatly ease this situation, so I've
created a dependency.

Comment 7

[Matthias Versen [:Matti]]

Security:general ?
Is there a security hole or why is this not in -> Networking:http ?

Comment 8

[Boris Zbarsky [:bzbarsky]]

This has definitely been filed before (though it may have been fixed and regressed)

Comment 9

[benc]

I think this has been bugging me in composer when I mistype...

Comment 10

[benc]

Caching the failed password is bad. Bug 55181 is an RFE, and stands alone.

I'm making this depend on bug 137852 for now, but we might re-arrange the some
of the bugs, b/c it isn't the plussed bug for fixing.

Comment 11

[Chris Nebergall ([e-mail])]

The browser caches the user's password when it is initally typed and sent.  It
does not wait for a 200 response.  If the web server responds with a 401 for the
exact same host, port, and realm then the cache is cleared and the user is
prompted again.

The seems to work fine if the web server doesn't do something funny like change
the realm in the 401.  If the web server tries this, the browser will not figure
out that the cache should be cleared.   Not sure if this is what your seeing,
but I thought I post just in case.

Comment 12

[Roland Felnhofer]

I have a lot of different realms (Basic authentication) on my Apache web server.
Since I've updated from nightly build 2003-06-12 to 2003-07-11 I encountered
some annoying affects.

Behavior nightly build 2003-06-12 and before:
I was asked once for my username and password. Afterwards I was able to access
all pages where my username and password was valid (all pages) even if it was a
different realm it seems to me Mozilla tried my already entered username and
password first and only if it was invalid (so the user and pw I used where not
member of the group assigned to that realm I got prompted again.

Example 1: (using "myusername")
Accessing: https://www.myserver.com/index.html [realm "Server Root"]
Get username and password prompt
Enter "myusername" and "mypassword"
Page appears.
Click link https://www.myserver.com/ADMIN/index.html [realm "Server Admin"]
Access granted (I'm also member of the group for this realm) - no dialog box for
entering password again appears! 

Example 2: (using "otherusername")
Accessing: https://www.myserver.com/index.html [realm "Server Root"]
Get username and password prompt
Enter "otherusername" and "otherpassword"
Page appears.
Click link https://www.myserver.com/ADMIN/index.html [realm "Server Admin"]
Dialog box for entering password appears ("otherusername" is not member of group
for realm "Server Admin"

Behavior since nightly build 2003-07-11 and after:
I get propted for entering the username and password each time I access a new
realm regardless if the logged in (cached username and password) would be valid
for this realm or not.

Example 3: (using "myusername")
like Example 2

Example 4: (using "otherusername")
like Example 2

Just to avoid "...have you tried to use password manager questions" - Yes it
does not solve the problem instead of having to re-enter the password I have to
use the filled out dialog and press "OK" for each new realm I enter. 

I checked the CVS tree and found out that quite a lot of changes have been made
in respect to username password caching during this time and I assume this
annoying behavior is a side effect of them. Even this behavior would be RFC
compliant - it's extremely annoying! In that case I would suggest to have at
least the possibility to make an entry in prefs.js like
"browser.cache.none_rfc_compliant_password_cache" to override this.

Comment 13

[Darin Fisher]

-> default owner

Comment 14

[Cees T.]

A 401 return code does not stop Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 from using incorrect Basic authorization. It should be flushed and the user prompted again. I do not want to shut down and restart my browser just beause i made a typo while logging in to a site.

Comment 15

[Matthias Versen [:Matti]]

You can flash the basic authentication now manually with the clear private data option. Is the other problem still there in recent Firefox versions ?

Comment 16

[Mark Côté [:mcote]]

I believe I hit this bug this week, with RabbitMQ's management-plugin UI, when importing a config file.  It happens every time and caused me much confusion until I looked at the outgoing requests and saw that the Authentication header did not change regardless of what I put into the password box, until I restarted Firefox.  I verified this happens on both latest Nightly and latest Release.  Here's how I reproduced:

1. Run "rabbitmqctl add_user admin admin1; rabbitmqctl set_user_tags admin administrator".
2. Log into UI with username "admin" and password "admin1".
3. Export broker definitions to a local file.
4. Run "rabbitmqctl change_password admin admin2".
5. Log into UI with username "admin" and password "admin2".
6. Import the definitions that were exported in step 3 above.
7. Log back into UI with username "admin" and password "admin1".

Expected: Login succeeds, since the old config, with the original admin password, was restored.

Actual: Login fails.  Note that the Authentication header is still "Basic YWRtaW46YWRtaW4y", which translates as "Basic admin:admin2".  Any other password at all results in the same Authentication header.  Restarting Firefox fixes the problem, sending the entered password as expected.

This may have something to do with the fact that the user is not logged out after the import, when the password is changed.  After import (between steps 6 and 7) I get a basic-auth dialog, which fails as the regular HTML login step 7 does (and redirects back to that page after failure).

I tried Chrome as well; everything works as expected there.

Comment 17

[Mark Côté [:mcote]]

Correction: the basic-auth dialog I mentioned near the end of comment 16 is irrelevant to the bug; RabbitMQ is just prompting for a login again before completing the import.  We have to enter the username "admin" and "admin2" to do the actual import, after which we get to step 7, where the (now incorrect) password "admin2" is sent via basic auth regardless of what is entered into the password field in the login page.

This is 100% reproducible if anyone needs more data.

Comment 18

[Shmuel]

Attachment: Don't cache http auth information by default.

I've added the DontCache flag to nsIAuthInformation. This flag indicates that this information shouldn't be cached.
nsLoginManagerPrompter.js sets this flag to true if the user has chose to save the information to the next time (the "Save in the password manager" checkbox).
nsHttpChannelAuthProvider::OnAuthAvailable says nsHttpChannelAuthProvider::GenCredsAndSetEntry if it should cache the information (its last new argument).

Summery: We'll cache the user's http auth information only if he has chose it.

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 8730002 [details] [diff] [review]
Don't cache http auth information by default.

Sorry, I'm really not active in Mozilla anymore. Switching this review over.

Comment 20

[Honza Bambas (:mayhemer)]

Comment on attachment 8730002 [details] [diff] [review]
Don't cache http auth information by default.

Review of attachment 8730002 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry, this patch is completely out of the scope of this bug and is actually wrong.  I don't want to waste time and go to the details.  At least, you have to cache the credentials to don't bother user when resources referred by a top level page behind auth are also behind auth.

few comments on how you can improve a next patch for any other bug you pick to try to fix

::: netwerk/base/nsAuthInformationHolder.cpp
@@ +34,5 @@
>      return NS_OK;
>  }
>  
>  NS_IMETHODIMP
> +nsAuthInformationHolder::GetDontCache(bool* aDontCache) 

trailing white space

can you please put your setter/getter pair together and not between other set/get pair of a different property?  probably putting it after domain setter and getter (as in the idl) would be appropriate.

@@ +87,2 @@
>  
> +

no added new line here

::: netwerk/base/nsIAuthInformation.idl
@@ +111,5 @@
> +
> +  /**
> +   * The user don't want this dialog's data to be cached.
> +   *
> +   * @see Bug 201620.

don't refer bugs please, this can be found via blame.

::: netwerk/protocol/http/nsHttpChannelAuthProvider.cpp
@@ +1161,5 @@
>      ident->Set(holder->Domain().get(),
>                 holder->User().get(),
>                 holder->Password().get());
>  
> +

don't add random blank lines.

::: netwerk/protocol/http/nsHttpChannelAuthProvider.h
@@ +56,5 @@
>                                   int32_t port, const char *dir,
>                                   const char *realm, const char *challenge,
>                                   const nsHttpAuthIdentity &ident,
> +                                 nsCOMPtr<nsISupports> &session, char **result,
> +                                 bool updateTheAuthCache);

put updateTheAuthCache before result

Comment 21

[Honza Bambas (:mayhemer)]

I believe this (or most of the bad effect here) is fixed by bug 137852.

I did some local testing and the behavior according the bug description could not be reproduced.  We reprompt when the password changes on the server side.

Please feel free to open a new bug if you find a good test case or steps to reproduce the original issue.

Comment 22

[Mark Côté [:mcote]]

I confirm that my test case in comment 16 is now working properly.  Thanks for duping!