If somebody connects to a site asking for a password using Digest Authentication, Mozilla should display in the Dialog that Digest, not Basic, is used; so that the user can be sure that the password is not transmitted in plain text.

-> http This would need to be done in the backend. I do think that some way of indicating secure vs non-secure authentication would be good, but I don't think that identifying the type of authentication would be understandable to most people. And of course, http-basic to an https site isn't really insecure, since the headers are going to be encrypted. Updating summary.

-> future do other browsers make such a distinction?

NS4 does not... but this has been a major annoyance for me in the past, when developing secure web sites. :)

This is an area where it would be great to give the user more info... I have wanted people to have some way of better understanding their level of exposure...

See also bug 136106 and bug 204992.

I think it would be good to have the type of auth selected appear in the dialog, maybe in the lower right. This would be one of those things that most people ignore, but power users would appreciate. It is simple, requires little UE design, and does not run afoul with potentially more complicated issues/solutions that are described in the related bugs.

nominating nsbeta1 Having multiple auth schemes is making life a lot more complicated. I know this UE change would be a cram, but it would really help w/ analysis, reduce bugs, and enhance usability. Look at the number of people that filed NTLM bugs that didn't even know what was going on...

benc: yeah, i agree with you. i'm just not sure if this is something that can be done before final. i'm not sure if there has been a UI freeze or what. -> suresh

adt: nsbeta1-

To me it would be even better if it were possible to select the auth method right from the user/pass screen. And to be able to save this preference on a domain basis. with a small advanced options part at the bottom which is collapsed by default, but can be expanded to reveal these settings eg: username [_______________] password [_______________] [+] Advanced features [-] Advanced features [digest \/] |ntlm | |basic | [x] remember this setting for this domain This would give ultimate control to the user. It should show a little lock icon so that the user can see if the method is safe ot not. This should be variable based upon SSL or no SSL.

I would like this to be an exception (to the poster's request): If the site/domain requesting login/password info is the same as your own domain, then all that stuff should be sent in the background. The reason I am asking for this is this: It is a must in a corporate setup. Doing it in any other way screws up all our efforts of single-sign-on.

Re: comment 1 and comment 6, the information not being useful or understandable to most users: I think it's probably true that most users will get little benefit from knowing if this authentication involves an MD5 or SHA digest or is taking place over TLS or not... but it can be boiled down to one simple point that is or should be understandable to every user, and Mozilla itself can determine the simple point based on the combination of digest/nodigest, TLS/no TLS, and so on. The simple point is, is this authentication material I just typed in this box going to be sent in the clear over an unencrypted connection, or not? *That* much should be definitely visible. It shouldn't be tucked away in a corner for power users to look at it. Power users are probably the last ones who need to be reminded that some of the sites they visit are requiring them to authenticate in a foolhardy way. See also bug 259982. The *details* of the mechanism can be tucked in the corner or behind an Advanced... button. And maybe a "you're about to send this unencrypted" warning can have a 'what could I do instead?' button that brings up either a help page or a wizard that describes how to set what auth methods you allow, or even analyzes the particular server to see what it can support. That could be a real benefit to a new user, but of course it's a more distant RFE. Making sure the user knows when an authentication will be insecure--that should not be distant future. For pie-in-the-sky UI enhancement, the UI could compare available auth schemes in a way useful to the user--that wouldn't be a dump of the particular acronyms and RFC numbers involved, but perhaps a number based on the hash length and currently available cryptanalysis research that roughly indicates the relative difficulty of compromise. That would be the kind of thing where a lot of knowledge is built into Mozilla but appears as a very straightforward and understandable UI element.

Not sure I agree with comment #12. Considering the recent implications of the Joux paper on hash function, MD5 is nearly useless (or soon to be) and not to excited about SHA1 either. While your common user might not understand this, your advanced user would. I would prefer in the login dialog box to know exactly what hash function is being used.

This feature will come in IE7 - the user will be warned when sending Basic auth info over an unencrypted HTTP connection. I think this needs to be done.

I think you should consider change in your approach. Typical user dont have to know what encryption method you implemeted. He only want to know it is safe. And he want to use friendly and simple UI. If you start adding milion options to simple Auth window, you're gonna turn FF to Opera :D So IMO this bug/feature should be done. You, as a developort should choose one, safest method and implement it. Sometimes forcing user to something is a better solution than giving him a choice.

this bug isn't about adding options to the auth dialog. it's about showing what auth type necko picked, or rather, whether a safe auth type was picked.

I must say that for the average user, I'd think it was more important to be notified when the auth method was *not* safe, i.e. when to reconsider sending the auth info.

In 3.0 pre builds, if user directly browses to site to perform authentication they will also know know if the site is using SSL as the URL is not color'd, nor is the lock icon in place yet when the authentication dialog is displayed.

This might be a dupe of bug 38019, at least it's related.

(In reply to comment #13) > Not sure I agree with comment #12. Considering the recent implications of the > Joux paper on hash function, MD5 is nearly useless (or soon to be) and not to > excited about SHA1 either. While your common user might not understand this, > your advanced user would. I would prefer in the login dialog box to know > exactly what hash function is being used. AFAIK, those papers dealt with collisions in MD5. They didn't have anything to say about being able to reverse an MD5 hash. I don't see how being able to find a collision for an MD5 will give you a user's password. Nevertheless, I agree that an advanced user would like to know what hash function is being used. I for one would like to know.

Jason: you were looking into these auth-dialog bugs like this one, right?

None of the individuals I've talked to in User Interface seems to think this is worth doing. Moving to UI, so y'all can decide. Move back to networking if and when there's a decision to do it and some spec of what you'd need from necko.

fwiw, I think bug 265780 is fixed enough that no necko work should be needed for this. I disagree that this isn't worthwhile (obviously, since I filed this bug), but since I assume that none of said individuals is cc'd to this bug this is maybe not the right place for that discussion.

Just adding a simple indicator of the type of authentication seems like it would be fine to me.

This related to rfe #548925 for the props to turn on/off security flags. I vote for as much details about what is happening in that dialog (auth mode, to which host and url, all the context possible). Later, firefox can automate a few decision based on rfe #548925 flags. Finally, but unlikely, the white/black listing of sites could be implemented, but that sound heavy lifting and could slow down that important security feature.

I think this is implemented in toolkit.