Closed
Bug 721001
Opened 12 years ago
Closed 12 years ago
[Mac] password entry fields not identified as such, entering password does not generate typical audible click
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla14
People
(Reporter: MarcoZ, Assigned: hub)
References
Details
Attachments
(1 file)
3.18 KB,
patch
|
tbsaunde
:
review+
MarcoZ
:
feedback+
|
Details | Diff | Splinter Review |
Password entry fields have the following problems: 1. Their role description is not properly identified. 2. When entering text, the typical password click that can be heard in Safari and elsewhere within Mac OS X is not being generated. I'm marking this bug security sensitive for now because I do not know if this can be exploited to somehow gain access to a user-entered password.
Reporter | ||
Updated•12 years ago
|
Priority: -- → P1
Comment 1•12 years ago
|
||
I don't think this is a security bug that needs to be hidden. The lack of sound might fool a user into not knowing it's a password field? But if so they wouldn't be entering their password. The lack of sound means they're lost and don't know which fields are which, resorting to guessing? Yeah, that's a problem, but if it's causing that kind of confusion people will know that even if they can't see this bug.
Group: core-security
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → hub
Reporter | ||
Comment 2•12 years ago
|
||
I was thinking more along the lines: Is there something in our APIs that might make password fields exploitable even if people enter something? But wasn't sure, so better to be cautious than sorry. :) Thanks for clarifying!
Assignee | ||
Comment 3•12 years ago
|
||
in Safari, "Secure Text Fields" return an empty value. We'll do the same with that patch.
Assignee | ||
Comment 4•12 years ago
|
||
Reporter | ||
Comment 5•12 years ago
|
||
Comment on attachment 613848 [details] [diff] [review] Intansiate the right class and set the proper subrole for password field. r= I built with this patch locally, and can confirm that a) VoiceOver announces password fields as "Secure Edit text" and that b) it clicks when typing in a password into such a field. The text is then not reviewable, which is correct.
Attachment #613848 -
Flags: feedback+
Assignee | ||
Updated•12 years ago
|
Attachment #613848 -
Flags: review?(trev.saunders)
Comment 6•12 years ago
|
||
Comment on attachment 613848 [details] [diff] [review] Intansiate the right class and set the proper subrole for password field. r= >- >+ >+ // A password text field return an empty value nit, returns
Attachment #613848 -
Flags: review?(trev.saunders) → review+
Assignee | ||
Comment 7•12 years ago
|
||
Thanks. And I'll also fix the typo in the commit log. I'll land tomorrow morning.
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c468f97100d
Target Milestone: --- → mozilla14
Comment 9•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6c468f97100d
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•