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)

enhancement
Not set
normal

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...
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
> 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.
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
ccing intl people for their opinion on that.
I don't see how that would work in practice. Would we also supply our own font with the glyph for all platforms?
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
The PUA in Unicode us for use by end users, not us.
(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)
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
Oops. Gerv
Status: RESOLVED → VERIFIED
Double oops! Gerv
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
This has too many implementation issues. Gerv
Status: REOPENED → RESOLVED
Closed: 20 years ago18 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.