[whatwg] <input type="password">... restrict reading value from JS?
sean at pbwhere.com
Mon Jul 11 06:29:23 PDT 2011
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"> because it will break websites that assumed they could read
the value. Perhaps a website checks against a user's past 10 passwords to
see if they are using the same one, via XHR. Or perhaps the entire login
process is XHR. Who knows.
I think there is definite room for improvements in security when it comes to
<input type="password">, and I've also been trying to make it more secure by
designing some sort of client-side hashing. But I don't think restricting
would just be a hassle for developers who need to read the value, and force
them to use another means of password entry where they can read the value.
On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:
> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> > This is just an idea.
> > For the last 10+ years, password inputs have been accessible from
> > with nary a complaint. If I have this code:
> > <div>
> > <input type="password" id="pw">
> > <button onclick="alert(document.getElementById('pw').value)">Show
> > password!</button>
> > </div>
> > </form>
> > I can extract the password by clicking on the button. More to the point,
> > with a XHR I can send that password somewhere it shouldn't go... (well,
> > cross-domain security code, maybe not, but that's not the point.)
> You can send it anyway by changing the action attribute on the form
> and calling submit(). So what attack scenario are you actually
> avoiding here? You'd need a really strong security benefit for it to
> be possible to even contemplate breaking so many websites.
More information about the whatwg