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
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
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
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
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
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
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
