435182 - UI should distinguish between HTTP Digest vs Basic auth

Status: RESOLVED DUPLICATE of bug 115500

(Core :: Security, defect)

Description

[Tim Lind]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5

When HTTP access authentication is used, there is no indication of the type of authentication that is being used, more importantly, there is no explanation to the user of the meaning of the security provided.

When I access a Digest protected site, the same prompt is showed as when I access a Basic protected site. As is noted in RFC 2617 this is one of the biggest vulnerabilities, where a security scheme can be downgraded without knowledge of the user.

(Opinion:
It is vital, especially at the moment, when users are only now becoming familiar with security schemes, that the meaning of these schemes are explained and heavily pointed out to users. 
)

The digest scheme, while protecting from eaves-dropping of a password, provides a more important feature that is not provided by the TLS connections users have come to appreciate...it provides the ability to not reveal the password to the receiving site.

Opinion:
This is something that is becoming more important as users sign up to several web services often with the same password, some services less secure than others.

With the rise of client side public key / hashing security infrastructures (or the ability of that rise that is not available without the help of client software),
users now need to come to understand that there is a difference between a "personal secret" and a "sitecode" (generated by the key), and that while the common use of a password uses the same for both, more secure and powerful schemes differentiate between the two, allowing them to use the same personal secret to generate many sitecodes so that they don't reveal the password used on their other sites.



Reproducible: Always

Steps to Reproduce:
1. Access a Digest protected realm
2. Access a Basic protected realm
3. Wait while the owner of the basic realm sees your password you use for many other services
Actual Results:  
No warning to the user about what happens with his/her password. 
The owner of the basic realm sees the password you use for many other services.

Expected Results:  
For digest auth: Tell the user that the password will not be revealed to the receiving site being logged onto, nor does it get transferred anywhere else.

For basic auth: Warn the user that the password will be seen by the receiving site they are logging onto (ask if they use this password for anything else) and indicate whether the password could be seen by anyone in between (encrypted or not).

Additionally, the password manager should store passwords and let the user choose from them, so that the user does not end up typing their digest password into a basic authentication, and rather they choose the password from a list (even if this is a new site they are authenticating against) and an even greater warning will be shown if they choose an existing password that has been used in another realm especially if it has been used with digest method.

With innovative authentication services coming up into use by users, it is important to provide for these schemes because they can often simplify the security implemented by the users resulting in more secure behave on the user part. Being able to use the same password across sites is one such innovative authentication service which should be provided for, it is also partly what digest authentication was designed for, and any scheme needs adequate support from the client / user interacting software.

Comment 1

[Jeff Walden [:Waldo]]

This seems to be primarily a UI enhancement bug, not one that's a vulnerability per se.  Is there a reason it needs to be kept secret?  UI bugs in particular benefit from more eyes than just the Mozilla security group.

Comment 2

[Tim Lind]

I thought I'd leave that option to those who deal more with vulnerabilities. It is definately a vulnerability, it's just solvable within the gui (although as I said should have more integration with the password manager...maybe I should have put it under that category), it's obtaining your password when you may think that you aren't giving it.
I'm sure it can be opened up though, as it's fairly obvious and a partial fix is trivial.

Comment 3

[Johnathan Nightingale [:johnath]]

Thanks for the detailed write-up.  I agree that Digest Auth is significantly preferable to Basic Auth, though I have still more love for schemes like SRP (bug 356855 ) which also resist offline attacks.

We can't change UI strings for Firefox 3 at this point, being past string freeze by a fair margin.  Even if we could, though, we have to weigh the advantages of user education here pretty carefully. Peter Gutmann is not wrong ( http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf ) when he blasts the tendency of developers to throw complicated questions back at the user.  In this case, I'm not sure that adding text - even the clear and readable text you suggest - will help the situation much, because I think it relies on the user having a more sophisticated model of things than they actually do.

"Of *course* my password is going to the website, that's the point"

is a plausible reaction, I think, and it takes *more* words to explain away that objection. That is not really the kind of UI that helps users make better decisions.  If we make things too cumbersome, sites will just change to form-based logins, for better or for worse.

I'd actually like to see us using more carrot than stick here.  If we think that DigestAuth or SRP or $new_technology_x are better solutions, we should provide favoured treatment in the browser.  Those mechanisms should be things sites want to participate in, given names like "Secure login" by the browser, host (appropriately verified) certificate logotypes, and be easy to implement (as digest auth already is).

Once those mechanisms are in place, I think it's appropriate to point to the old dialogs and mark them with more than words - signal "Warning: Insecure Login" with a big caution sign; make it clear to the user that there's a problem here.  But I think those things go hand-in-hand with better support for "good" approaches.

I know this seems like a tangent, and you were mostly just arguing for a wording change, but I also think you sound like you're focused on the long term improvement of the landscape here.  I'm going to confirm the bug and update the summary to reflect what I think you're focusing on, but I think maybe the right approach is more than just elaborated wording.  I'm also going to unhide it since the attacks here (passive sniffing, or active downgrade attacks) are well-known, and hence there is little advantage to keeping the bug secret.

Comment 4

[Tim Lind]

A user will only have a certain model of something if the browser gives them that model, which is exactly what I'm suggesting. And as you pointed out, we need to favor these things in order for sites to use them, at the moment, the most well standardized method (http access authentication) is given poor treatment, I don't even get an "invalid login" when I put the wrong credentials in, it just loops.

I was never going for just wording changes, I'm suggesting a need for a semantically different view given to the user, which the password manager could be based around in order to provide greater security.

With regard to needing many words or offering a cumbersome view, I've proposed something which in my opinion provides good security semantics and the model is very simply understood by the user. 
You said "Of course my password is going to the website..." but it is before that point that we need to address this, that is exactly why I believe the two keywords which you failed to make use of are so important:
Users are no longer entering passwords, they are entering "personal secrets" which are used to generate complex "site passes" (site passes are usually completely unmemorable). A simple dialog which emphasizes these two entities, and indicates what information is being sent over the network and what is kept in the users personal space is what is needed. Just one warning sentence  such as 'dont send a personal secret if you use it on any other sites' provides enough momentum for them to understand.

And I believe that this opens up alot of opportunity to the password manager to secure those passwords against phising or keylogging if that "personal secret" is stored and never used on a site that requests the personal secret as opposed to site pass. Users then come to love not sharing personal secrets because they can safely use these in many places-they look suspiciously at sites that require more than site passes & put pressure on the sites to require no more than site passes, and sites adopt the http access authentication because it hooks into the users usage patterns and provides an adequate (unlike the present implementation of http access authentication) and strong authentication system (the result of central effort).

I'm not familiar with the freeze cycle of firefox and couldn't find any info, but can you estimate -assuming for a moment that this is supported by developers- when this sort of interaction might be implemented?

Should I change this to the password manager or phising protection component so that it gets their attention?

Comment 5

[Daniel Veditz [:dveditz]]

This isn't really password manager, that's just the mechanism for remembering and replaying passwords. It's also most likely a "Core" issue, not a Firefox front-end one, since these prompts are generated from core Networking Auth code. (they _could_ be overridden by Firefox alone, but if we think we've got a better solution we'd want all Mozilla clients to share if possible.)

Comment 6

[Justin Dolske [:Dolske]]

I share the same concerns as Johnath. I'd additionally note that Digest auth isn't widely deployed, and I'm pessimistic about that changing, given that it's just an incremental improvement on Basic auth and has been around for years.

Improving the authentication experience and trying to get away from Basic auth are definitely goals to pursue, but I don't think Digest auth is the right vehicle for that.

Comment 7

[Tim Lind]

But *why* isn't digest auth widely deployed?

Even so, embracing a standard http access authentication method is going to promote development, support and uptake of a more semantic and common authentication mechanism, as opposed to basic customized human forms not really usable by software agents.

Also, as I said, digest does have important features, such as allowing secret knowledge to be kept secret and safely reused for different sites, which is what current efforts seem to be aimed at, such as openid, that implements a fairly insecure (to phising) authentication method that achieves this common password.

More importantly, the differentiation between secret knowledge and site passes that I suggest isn't something just used by digest auth, it's also the same concept that public key schemes use. It gives greater security because a site pass is generated that is based on the site that the password is being sent to, so one site will not receive the site pass used on another site...provided the client software helps the user to not enter or send the secret knowledge in the wrong place...

Comment 8

[RNicoletto]

Is this a DUPE of bug 115500?