Re: [whatwg] input type=password... restrict reading value from JS?

2011-08-01 Thread Aryeh Gregor
On Fri, Jul 29, 2011 at 9:53 PM, Bjartur Thorlacius svartma...@gmail.com wrote: So there are two use cases for reading user passwords:  * client side password strength indicators  ** telling users if their passwords conform to site specific password restrictions  - arguably bad practice  -

Re: [whatwg] input type=password... restrict reading value from JS?

2011-08-01 Thread Bjartur Thorlacius
Þann mán 1.ágú 2011 15:25, skrifaði Aryeh Gregor: If you're doing useful password strength checks, regular expressions won't cut it. For instance, you'll want to check against dictionaries. Regex is only useful for crude and ineffective checks like must be at least six characters long with

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-29 Thread Bjartur Thorlacius
On 7/11/11, Sean Connelly s...@pbwhere.com wrote: As a web developer, if I wanted access to the password, I would then avoid using the input type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. Fair point. I also worry

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-11 Thread Sean Connelly
As a web developer, if I wanted access to the password, I would then avoid using the input type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. I also think it's a bad idea to change the behavior of input type=password

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-11 Thread Tom O'Connor
We would likely end up with some more of these lovely interfaces: https://online.westpac.com.au/ Try using that without a mouse and not going insane/grossly disclosing your input to anyone paying mild attention to your screen. Tom On 11/07/2011 23:29, Sean Connelly wrote: As a web

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-11 Thread Bjartur Thorlacius
Þann sun 10.júl 2011 08:08, skrifaði Alex Vincent: /** * Check if a password field's value matches another. * * @param otherPassword Another password element. * * @throws Error if this.type != password * @throws Error if other.type != password * * @returns Boolean True if the

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-11 Thread Tab Atkins Jr.
On Sun, Jul 10, 2011 at 3:44 AM, Alex Vincent ajvinc...@gmail.com wrote: On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski lcam...@coredump.cxwrote: For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint.  If I have this code: Unfortunately, the

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-11 Thread Aryeh Gregor
On Mon, Jul 11, 2011 at 9:29 AM, Sean Connelly s...@pbwhere.com wrote: As a web developer, if I wanted access to the password, I would then avoid using the input type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. Then

[whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Alex Vincent
This is just an idea. For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint. If I have this code: form action=javascript:void div input type=password id=pw button onclick=alert(document.getElementById('pw').value)Show password!/button

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Dennis Joachimsthaler
Hello Alex, may I ask: Why? This would only cover a few cases of cross-site-scripting attacks. It would not make a website more secure. As to the suggestion, I have one little concern: It should not be possible to WRITE those SecurePassword values. You only wrote reading... Also it would

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Michal Zalewski
For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint.  If I have this code: Denying access to password fields from JavaScript is actually a somewhat interesting security enhancement when you consider the behavior of password managers. Right now, if

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Alex Vincent
On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski lcam...@coredump.cxwrote: For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint. If I have this code: Unfortunately, the problem is not that easy to fix: denying access to the field does not

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Dennis Joachimsthaler
How about deleting the value if the input type is changed away from the secure password input type AND that the secure password can only be submitted to a similar URI. Am 10.07.2011, 12:44 Uhr, schrieb Alex Vincent ajvinc...@gmail.com: On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Michal Zalewski
How about deleting the value if the input type is changed away from the secure password input type AND that the secure password can only be submitted to a similar URI. Right now, for interoperability, password managers allow a good amount of fuzziness when matching forms, and I do not believe

Re: [whatwg] input type=password... restrict reading value from JS?

2011-07-10 Thread Dennis Joachimsthaler
Hello, Opera, for example, requires you to hit the wand or login button before it even does any autocompletion. I wish all browsers would implement it like this instead of just... Filling it out before the user can interact. Makes reading easy. Am 10.07.2011, 21:17 Uhr, schrieb Michal