Closed
Bug 287090
Opened 20 years ago
Closed 18 years ago
Use locks instead of asterisks in secure password controls
Categories
(Core :: Layout: Form Controls, enhancement)
Core
Layout: Form Controls
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: gerv, Unassigned)
Details
We should change the password control so that if the site is secure, we use
little padlocks instead of asterisks.
Rationale: most phishing sites currently don't use SSL, and we want to raise the
bar by forcing them to. Having password controls look different on secure sites
would be a clear "suspicion-raising point" for users entering sensitive
information into insecure forms. There can't be too much of a usability problem
with changing the glyph; at the moment, IE uses a round dot and we use a *.
We'd need to make sure it wasn't possible to use DHTML to spoof the padlocks,
perhaps by giving focussed password controls infinite z-order.
[Apologies if this is in the wrong component.]
Gerv
(In reply to comment #0)
> We should change the password control so that if the site is secure, we use
> little padlocks instead of asterisks.
>...
> Gerv
Something like
http://lxr.mozilla.org./mozilla/source/browser/themes/pinstripe/browser/Secure.png
would look good, except it would have to be smaller in my opinion. This would be
quite a good way of ensuring people that when they enter passwords they are
sending them securely (the form action would need to be checked in this case
though; insecure form submissions from a secure page should not display the
secure glyph.)
On a side note, Windows XP upgraded their password-masking system. The glyphs
are no longer just masks for the characters underneath, but only represent a
character. This stops password-revealing tools from working. It's slightly
unnerving to notice that the web-developer extension in Firefox has a 'Show
Passwords' option for forms, which plainly reveals what is in the password field...
Reporter | ||
Comment 2•20 years ago
|
||
Good point about checking the target. In fact, we'd need to do a proper new
nsIURI or whatever - matching "^https://" of course won't cut it.
> It's slightly unnerving to notice that the web-developer extension in Firefox
> has a 'Show Passwords' option for forms, which plainly reveals what is in the
> password field...
Why is that unnerving? If the browser didn't know what you'd typed, it couldn't
send it. And, if it knows what you've typed, it can be commanded to reveal it.
Gerv
![]() |
||
Comment 3•20 years ago
|
||
> insecure form submissions from a secure page should not display the
> secure glyph.
HTTP redirects mean you can't detect this situation until after you've submitted
(consider an https: form action that redirects to an http: URL... and yes, these
are out there).
Gerv, the plaintext editor (used by password controls) is just that -- a
plaintext editor. Is there a Unicode character that looks like what we want?
And is it likely to be on the user's system? If not, this is likely to require
heavy editor lifting to do.
Reporter | ||
Comment 4•20 years ago
|
||
Boris: the idea is to make sure the site has a certificate _somewhere_ (for
accountability) - so and form that submits to HTTPS would have the feature,
whether it later redirected or not.
Your point about the plain text control is a good one, however. I don't think
there's a suitable glyph in Unicode; I do remember looking once. However, there
are "reserved for private use" spaces, so perhaps we could invent and use our
own glyph that way?
Gerv
![]() |
||
Comment 5•20 years ago
|
||
ccing intl people for their opinion on that.
Comment 6•20 years ago
|
||
I don't see how that would work in practice. Would we also supply our own font
with the glyph for all platforms?
Reporter | ||
Comment 7•20 years ago
|
||
Simon: I was assuming that it wasn't massively difficult to create a font file
containing only that glyph, in a cross-platform format we understand, ship it
and just use it internally.
However, having now written that sentence, I can understand that there may be
more to this than I think. Is there?
Gerv
Comment 8•20 years ago
|
||
The PUA in Unicode us for use by end users, not us.
Comment 9•20 years ago
|
||
(In reply to comment #8)
> The PUA in Unicode us for use by end users, not us.
I don't think this is correct. See the sections on the "corporate use subarea"
and the "end-user subarea" on pp. 398-399 of the Unicode standard
(http://www.unicode.org/versions/Unicode4.0.0/ch15.pdf)
Reporter | ||
Comment 10•20 years ago
|
||
The only way we could do this is if a focussed password field suddenly acquired
infinite z-order, so that no other content could be laid on top to spoof the
lock icons.
Gerv
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 12•20 years ago
|
||
Double oops!
Gerv
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Reporter | ||
Comment 13•18 years ago
|
||
This has too many implementation issues.
Gerv
Status: REOPENED → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•