338050 - Password Manager doesn't cope with changing authentication realms

Status: VERIFIED WONTFIX

(Toolkit :: Password Manager, enhancement)

Description

[Eloy Paris]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060326 Firefox/1.5.0.3 (Debian-1.5.dfsg+1.5.0.3-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060326 Firefox/1.5.0.3 (Debian-1.5.dfsg+1.5.0.3-2)

It's becoming increasingly annoying that some sites that require authentication change slightly the authentication realm so the Password Manager is fooled into thinking that there is no saved password for that site, even though the user has visited that site before, and there's a password saved for that site (although for a slightly different authentication realm.)

Reproducible: Always




Currently, my saved passwords include something like this:

Site                                               Username
----                                               --------

www.example.com:80 (Auth. Realm [08:05:02:7021])   userid
www.example.com:80 (Auth. Realm [08:05:22:9726])   userid
www.example.com:80 (Auth. Realm [09:34:58:2679])   userid
www.example.com:80 (Auth. Realm [11:35:31:5316])   userid

All these entries refer to the exact same site, same directory, and same user ID and password. However, because the site dynamically adds a time to the authentication realm, from the current point of view of Password Manager, there really isn't a saved password for this site, so I get prompted for a password every time I log into this site and can't use a saved password.

This bug is an enhacement request so something can be done to prevent this, i.e. so when a site chooses to use this simple obfuscation of the authentication realm, Password Manager recognizes that the changing realm is something that it already has a saved password for.

A possible solution for this problem would be to be more flexible on the way we match the authentication realm that is been sending to us with the realm that we save with Password Manager data. For example, the Password Manager saved realm could be made a regular expression instead of the fixed string it is today. Then, the UI could be tweaked so (power) users can go to the Password Manager and manually edit the authentication realm and change it to a regular expression. Heck, even manually editing signons.txt to change the saved realms to regexes would be fine.

Unfortunately, I don't have a public URL that can be used to see this behavior, but an increasing number of internal sites in my corporation are rigged with this annoying "security" mechanism. Hopefully someone will be able to provide an example...

Comment 1

[Alun Evans]

So I'm glad it's not just me in that organisation that's been driven mad by
this "feature".

So looking through the source of firefox-1.5.0.7-1.fc5, there seem to be two
possible places to handle this.

First, in nsHttpChannel::ParseRealm() where the realm is extracted from the challenge

(gdb) p challenge
$2 = 0xbfd77240 "basic realm=\"my-realm [07:33:09:8549]\""

i.e. all realms could be passed through a filter, which seems kinda dangerous.


Secondly, in nsHttpAuthNode::LookupEntryByRealm(), where the realm is compared
to the cached realms for the authnode:

    for (i=0; i<mList.Count(); ++i) {
        entry = (nsHttpAuthEntry *) mList[i];
        if (strcmp(realm, entry->Realm()) == 0)
            return entry;
    }

Regexp here would be good, though then the issue then becomes setting the
regexp, perhaps the password dialog box could provide a "edit realm" tick box?


I saw a regexp implementation for javascript, though I have no idea if it's
even possible to invoke it from here.

The other question I guess, is where this should be done here, or infra should
be added to allow an extension to do this work.

Comment 2

[Justin Dolske [:Dolske]]

This is expected, per RFC 2617:

2 Basic Authentication Scheme

   The "basic" authentication scheme is based on the model that the
   client must authenticate itself with a user-ID and a password for
   each realm.  The realm value should be considered an opaque string
   which can only be compared for equality with other realms on that
   server.

A non-strict realm check would likely be considered a security problem, as it could result in sending the credentials for one (opaque) realm to another.

Comment 3

[Mike Connor [:mconnor]]

if sites are randomly changing the auth realm, they're probably doing it to break password management anyway, and they'd just change to something that'd be less regexp-hackable.