115500 - http authentication dialog should display type of auth (basic, digest, etc.)

Status: NEW

(Toolkit :: General, enhancement)

Description

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

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.

Comment 1

[Bradley Baetz (:bbaetz)]

-> 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.

Comment 2

[Darin Fisher]

-> future


do other browsers make such a distinction?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[benc]

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...

Comment 5

[Jo Hermans]

See also bug 136106 and bug 204992.

Comment 6

[benc]

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.

Comment 7

[benc]

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...

Comment 8

[Darin Fisher]

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

Comment 9

[Samir Gehani]

adt: nsbeta1-

Comment 10

[Jesse Houwing]

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.

Comment 11

[adem baba]

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.

Comment 12

[Chapman Flack]

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.

Comment 13

[u17130]

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.

Comment 14

[Daniel Schierbeck]

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.

Comment 15

[Pawel Borkowski]

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.

Comment 16

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

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.

Comment 17

[Daniel Schierbeck]

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.

Comment 19

[lsg-mtso]

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.

Comment 20

[Kai Engert [:KaiE:]]

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

Comment 21

[Tim Olsen]

(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.

Comment 22

[Daniel Veditz [:dveditz]]

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

Comment 24

[Jason Duell]

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.

Comment 25

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

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.

Comment 26

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

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

Comment 27

[quartz12h]

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.

Comment 29

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I think this is implemented in toolkit.