190914 - Default unknown input types to "password" instead of "text"

Status: VERIFIED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Ralf Hauser]

As opposed to http://bugzilla.mozilla.org/show_bug.cgi?id=190797, I no longer
think defaulting to text is ok., because this opens a security hole and violates
"fail-safe" principles".
If a user types a password into an input field of type "pasword", a person
standing behind that user will the password - it is compromised.
Or rather: "password" is a more restrictive type than text, therefore, it
anything is use at all (instead of just displaying an error) it should be used
instead of "text"

Comment 1

[Boris Zbarsky [:bzbarsky]]

The HTML spec explicitly states that unknown types must default to "text".

And this is very much in the wrong component....

Comment 2

[Boris Zbarsky [:bzbarsky]]

Marking invalid, since this behavior is forced by the spec.

Comment 3

[Ralf Hauser]

So, it is Mozilla's policy to rather be standard compliant than secure
(admitted, it is not a particularly dangerous security hole)?

So far, I thought compromising security for convenience was reserved territory
of MS ...  ;)

Comment 4

[Boris Zbarsky [:bzbarsky]]

> So, it is Mozilla's policy to rather be standard compliant than secure

No, when there is a security hole...  I don't believe this to be a security
hole, however.  It's no worse than a web designer using <input type="text"> for
the password field (and a hell of a lot more rare, I would think, since people
usually _test_ their pages).

That said, I've cced the security module owner, as you may have noticed, in case
he disagrees.  If he does, he will reopen the bug.

> compromising security for convenience 

Where is the convenience?

Comment 5

[Mitchell Stoltz (not reading bugmail)]

> So, it is Mozilla's policy to rather be standard compliant than secure

No, it's Mozilla's policy to evaluate security vs. usability tradeoffs on a
per-bug basis. In this case, I agree with bz that the risk is too low to justify
breaking the spec in this case, especially since this will never happen on a
properly coded site.

Comment 6

[Ralf Hauser]

Agreed, the risk is very minor, but
i) from all the major exploits I have read about, idiotic things like this one
were almost always an important contributary puzzle piece for the overall attack
ii) I wouldn't expect that all sites are "properly coded" and benevolent -
especially in today's adversarial environment, this is exactly the point that
almost in the form of "social engineering", an attacker may lure the victim on a
badly coded site to get their password because my experience from seeing people
putting their password into login windows durning demos by mistake, only about
50% will change the password even after a significant audience has seen it...
(Sure if the attacker controls the "lured-to" site, they could put in type
"text" anyway, but this way, they could easier use third-party errors for such
an attack and not raise suspicion)

P.S.: Another area where Mozilla IMHO assumes a way too benevolent environment
is certificate Management: http://bugzilla.mozilla.org/show_bug.cgi?id=185243,
http://bugzilla.mozilla.org/show_bug.cgi?id=184659, ... What prevents attackers
from putting up a rogue CA site and trying to mess up Mozilla users' certificate
stores because for convenience reasons (apparently designed to complement a now
defunct Netscape CA product), they are shielded from most of the
useful/necessary(?)  dialogs putting the user in charge?