38019 - [rfe] add PSM lock icon to password dialogs

Status: RESOLVED DUPLICATE of bug 333521

(Core Graveyard :: Security: UI, enhancement, P4)

Description

[Hugh Kennedy]

this is branched out from bug 38008.

the password dialog should reflect whether or not it will be passing
the auth string over a secure connection or not.

Comment 1

[Norris Boyd]

Reassign to owner of Security:Crypto component.

Comment 2

[John Unruh]

Setting milestone to Future.

Comment 3

[Doug Turner (:dougt)]

Reassigning all https/cartman/security bugs to valeski.  He will be finding new 
owner(s).  This shift is so that I can focus on embedding issues.  If the new 
owner has questions that can not be resovled, I may be able to lend a (quick) 
hand.

over to valeski....

Comment 4

[David P. Drinan]

Re-assigning all valeski PSM bugs to ddrinan.

Comment 5

[John Unruh]

nsbeta1

Comment 6

[David P. Drinan]

Mass changing of product. Browser:Security:Crypto --> PSM 2.0

Comment 7

[Aleksey Nogin]

*** Bug 33184 has been marked as a duplicate of this bug. ***

Comment 8

[John G. Myers]

*** Bug 76493 has been marked as a duplicate of this bug. ***

Comment 9

[Stephane Saux]

Mass reassigning target to 2.1

Comment 10

[Stephane Saux]

remove nsenterprise.

Comment 11

[Javier Delgadillo]

New Feature->P4

Comment 12

[Stephane Saux]

Moving all P3 and P4 bugs targetted to 2.1 to future.

Comment 13

[John Unruh]

Mass assigning QA to ckritzer.

Comment 14

[Kai Engert (:KaiE:)]

I agree the password dialog should show whether the password will be transfered
securly or not. See also bug 143552, which is probably a duplicate.

Comment 15

[John Unruh]

*** Bug 143552 has been marked as a duplicate of this bug. ***

Comment 16

[Kai Engert (:KaiE:)]

-> me

Comment 17

[Kai Engert (:KaiE:)]

I agree that a lock icon would be the nicest looking solution.
But at the moment, I don't want to spend at lot of time on this issue.

(We would have to go away from the current implementation of just using a simple
default dialog, and would have to implement a new XUL dialog, we would have to
query the security status of the initial connection attempt, etc. Sure, doable,
but not in 30 minutes.)


But still, I think it is important to give the user at least some feedback
whether the entered password will be sent with or without encryption.

I have a small patch that slightly extends the password prompt.
If the protocol is not http, it prefixes the hostname with protocol://

This seems reasonable to me, since we already suffix the displayed hostname with
a :port if the connection is to a non-standard port.


As a result:
If the user connects to a site without encryption, the message we display will
not change by this patch. The user will continue to see a message like:

  Enter username and password for "realm" at www.acme.com

If the connection is using https, the message will look like:

  Enter username and password for "realm" at https://www.acme.com


I created a test site at:

  http://www.kuix.de/misc/test35/
  https://www.kuix.de/misc/test35/

to see the port numbers in the prompt use:
  http://www.kuix.de:80/misc/test35/
  https://www.kuix.de:443/misc/test35/

  user: test35
  password: test35

Comment 18

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Darin, what do you think?

Comment 19

[Darin Fisher]

Comment on attachment 92880 [details] [diff] [review]
Patch v1

yeah, this seems like a good addition.	one thing though...  imagine FTP
proxied connections.  the scheme will be ftp://, but in reality the protocol is
http://. so do we want the dialog to say ftp:// or http:// and if we choose
ftp://, then what about the normal FTP password dialog?  should it also include
the text FTP (if it doesn't already)?

Comment 20

[Kai Engert (:KaiE:)]

I think we should show show ftp:// - the patch does already do it.

I just tested, and with the patch and using a proxy, we indeed display the
prompt to enter both username and password, and it shows ftp:// already.

My tests show the FTP password prompt already prefixes the hostname with ftp://

If you want to see the current behaviour yourself:
- an internal proxy is carbuncle.mcom.com 8080
- connect to ftp://[e-mail]/

So if we agree, that we show ftp://, we should be fine already.

Comment 21

[Darin Fisher]

there is another issue BTW... what about Digest authentication?  it is a secure
mechanism for transfering someones password.  however, it can be used with
normal HTTP connections.  so, in other words, the protocol scheme doesn't really
indicate the security level.

Comment 22

[Kai Engert (:KaiE:)]

So the point is: Although one uses a http connection without an SSL encryption
wrapper, the password will not get transmitted as cleartext.

I'm still trying to keep it simple.

I extended the generic authenticator interface to support the scheme it is using
and make use of that in the http channel implementation. I temporarily thought
about making the implementor class of the authenticator return an additional
message on its own, but I did not want to add string bundle access to the
authenticator implementations.

As of now there are only basic and digest authentication, I suggest, if a digest
mechanism is in use, we append
  (uses digest authentication)
to the message.

I have created a digest auth test site at: http://www.kuix.de/misc/test35digest/

Comment 23

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Comment 24

[Darin Fisher]

i don't think average users are going to understand what "using digest
authentication" means.  that is a very technical term.  can't we say using
secure authentication or something more general?  or what i'd really like is a
separate message saying either

  "Your username and password will be encrypted before being sent over the
Internet."

or

  "Your username and password will be sent over the Internet without encryption."

perhaps it's possible to extend nsIAuthPrompt to include a security flag?

Comment 25

[Kai Engert (:KaiE:)]

I don't think the average user is able to understand what https means either.

If we want to show more detailed explanations in the dialog, we should not only
explain what digest authentication means, we should also explain what https
means when it is in effect.

And that leads to the question: What message should we show if both https and
digest authentication are in effect at the same time?

Comment 26

[Kai Engert (:KaiE:)]

CC'ing Sean, since we are starting to talk about security wordings.

Comment 27

[Kai Engert (:KaiE:)]

Let's try to agree before I create more patches.

New plan:

We currently say "Enter username and password for "realm" at www.acme.com"


1.) The first suggestion was to include the protocol for non-http authentication
like in "Enter username and password for "realm" at https://www.acme.com"

Any objections on adding the prefix?


2.) Adding the protocol is not enough information to help the user. We should
also say whether a protection will be used or whether secure authentication will
be used. In addition it was suggested to warn the user if none of these
mechanisms is in use.

New suggestion for the different scenarios (ignoring the protocol prefix above.):

2a) If there is neither https nor a digest/secure authentication in effect we
say: "Enter username and password for "realm" at https://www.acme.com. Your
username and password will be sent over the Internet without protection."

2b) If there is a secure digest authentication in effect, but we are not using
https: "Enter username and password for "realm" at https://www.acme.com. Your
username and password will be sent over the Internet using secure authentication."

2c) If we are going to use https, we assume that https is stronger than the
digest authentication. We will not mention the digest authentication, regardless
whether it is used or not. So with https we could say: "Enter username and
password for "realm" at https://www.acme.com. Your username and password will be
sent over an encrypted connection."

I wonder whether we should try to find a wording where we avoid having to say
"username and password" twice.

Comment 28

[Darin Fisher]

Ignoring the "https://" prefixes ;-) your 3 suggested wordings seem good to me.
 I'm not sure that it would all fit in the title of the window though.

nsIAuthPrompt isn't frozen, so we could look into adding an additional field.

Comment 29

[Kai Engert (:KaiE:)]

Darin and me had a chat and agreed on the following:

- nsIAuthPrompt is used all over Mozilla, not only for http/ftp
- the implementation of nsIAuthPrompt should not have to deal with the message shown
- at this time, we don't want to change the implementation of nsIAuthPrompt to
show more security info besides the message we pass to it
- at a later time, someone might choose to extend the implementation of
nsIAuthPrompt to show additional info in the dialog, like lock icons or SSL
trust information
- the interface nsIAuthPrompt is not yet frozen, but it is likely it will be
soon. Because of that, if we want avoid complication, we should extend the
interface now
- we can extend the interface to include the security state
- we can pass over the security from the http/https code
- because nsIAuthPrompt is used all over Mozilla, it is not possible for me (in
a short time) to add the correct security state to all the other usages of that
interface
- therefore, we'll add a new parameter like SECURITY_UNKNOWN wherever I need to
change code outside of security/http to make it compile
- in addition, I think we should add more than one parameter. Besides an enum
like unknown/cleartext/obscured/digestauth/encryption we should also pass over
an optional nsISupports*, that may be null. We can use that later to pass over
SSL trust information

Comment 30

[Kai Engert (:KaiE:)]

Attachment: Patch to nsIAuthPrompt only

Darin, I would like to agree on the interface first. What do you think?

Comment 31

[Darin Fisher]

yeah, this is what i had in mind too :)

Comment 32

[Kai Engert (:KaiE:)]

I see that implementations of nsIAuthPrompt mostly forward directly to nsIPrompt
and nsIPromptService.

Isn't it useless to change only nsIAuthPrompt, but not the other two?

I'm a bit scared by the amount of work required to change everything.

The sum of occurrences of prompt, Prompt, promptPassword, PromptPassword,
promptUsernameAndPassword, PromptUsernameAndPassword is => 533. I would have to
read and possibly extend 533 places in our code.

Even if we decided to only change nsIAuthPrompt, I still have to check that many
places, because without reading them, I don't know whether it is a call to
nsIAuthPrompt or something else, and whether it needs a change.

I want to give up for now and push this bug back, unless we agree it's a higher
priority or agree on a simpler solution.

Comment 33

[Darin Fisher]

ultimately, nsIAuthPrompt doesn't need to be implemented as calls to nsIPrompt.
 it could be implemented differently, or it could be implemented just as it is
today.  by making the API changes to nsIAuthPrompt, you push the burden of how
the security state is conveyed to the user up and out of networking (where it
rightfully doesn't belong).  as an intermediate solution, can't you append some
warning text to the text supplied by the caller of nsIAuthPrompt?  it could be a
separate sentence, making it less likely to break internationalization, right? 
how about a couple newline chars or something to completely break it away from
the existing text?

Comment 34

[John G. Myers]

The SECURITY_* values should reflect the strength of the protection, not the
particular mechanisms used.

Security is desinged around a threat model.  A threat model enumerates and
classifies the types of attacks, their estimated costs to the attacker, and
their costs to the victim.  One then implements countermeasures to the specific
attacks.

The interesting information to the user is not so much which particular
countermeasures are being taken, but which class of attacks they are vulnerable
to.  For authentications, the interesting attacks are:

1) Passive eavesdropping -- The attacker taps the network and retrieves the
password as it goes by.
2) Offline dictionary attack -- The attacker taps the network and retrieves
information useful in performing a dictionary attack against the user's password.
3) Spoofing or interception attack -- The attacker pretends to be the server or
modifies the communications between the client and the server and is able to
trick the client into sending it information from which the password may be
retrieved.
4) Connection hijacking -- The attacker permits the client to authenticate to
the server then takes over the connection, using the client's authentication to
send its own set of commands to the server.

Both digest and SSL (with sufficiently large key sizes and a valid cert) protect
the password against attacks 1-3.  SSL also protects against attack 4.  There
are mechanisms (such as APOP and CRAM-MD5) which protect against only 1 and 3.

"Obscuring" offers no protection whatsoever.  It shouldn't be called out as a
separate value.

SSL can offer either weak or strong protection against 1, depending on the size
of the stream cipher.  These two levels of protection should be called out
separately, as they are for browser windows.  (It can also provide weak
protection against 3, but that is related to bug 134735.)

Comment 35

[Hugh Kennedy]

it is necessary but not sufficient to list the strength of the protection.
you must also at least provide means for interested parties to determine the
mechanism of protection, as what was "highly secure" when the software was
shipped may have been exposed as broken yesterday.

good threat models are not static :-)

Comment 36

[timeless]

this also affects mail. (imap, pop, smtp, news, snews, ...)

Comment 37

[John Unruh]

*** Bug 189582 has been marked as a duplicate of this bug. ***

Comment 38

[Matthias Versen [:Matti]]

*** Bug 204992 has been marked as a duplicate of this bug. ***

Comment 39

[Samir Gehani]

adt: nsbeta1-

Comment 40

[Stefan Borggraefe]

*** Bug 227362 has been marked as a duplicate of this bug. ***

Comment 41

[Jo Hermans]

*** Bug 322703 has been marked as a duplicate of this bug. ***