4 ms·

Stupid question: why not make password-marked fields something that JS engines simply can't read from? I imagine it would stop you from client-side warnings of

by SilasX 7y ago

Stupid question: why not make password-marked fields something that JS engines simply can't read from? I imagine it would stop you from client-side warnings of password insecurity, but is there a bigger problem?

ceejayoz 7y ago
It would kill any site with an AJAX-based login. Twitter, AirBnb, Facebook, Google, Apple...
- bmm6o 7y ago
  Yeah, posting a form to login in is the exception nowadays.
- chopin 7y ago
  A good thing, imho.
noodlesUK 7y ago
I imagine it would be pretty easy for the js to just remove the element from the DOM and replace it with a similarly styled input if all we are doing is stopping it reading the contents of the password input
lucb1e 7y ago
I use JavaScript on some password fields for client-side password hashing (reasoning: https://security.stackexchange.com/a/201099/10863 https://security.stackexchange.com/a/201099/10863), but I agree that this might be a useful thing. I can think of a few ways this could work: - Blacklist or whitelist access: <input type=password nojs> or <input type=password allowjs> - Specifically set a method that is called upon form submission: <input type=password onsubmit=hashPassword> <script>function hashPassword(value){ ... }</script> The catch here is that the browser would have to error out on reassignment of the hashPassword global variable, since that is what malware would do. This sounds easy, but it might be quite a bit more complexity for the browser's JS engine, since it has to check every assignment in the global scope against a list of functions that are used for password fields. - Only allow access from the code path starting with the form's onsubmit event, so <form onsubmit="return validate(this)">. The catch here is that most modern websites do $("#myform").onsubmit=function(){...} which any malware could do as well, so that would have to be disallowed. A lot of devs wouldn't be happy about that. Though for backwards compatibility, the opt-in method would probably be the only candidate for actual implementation in the foreseeable future.
- blacksmith_tb 7y ago
  That's a tricky one, though - you're basically deciding for your users if their credentials will be at risk. As one of your users I'd rather make that call for myself...
  - lucb1e 7y ago
    You're always making that call, either client or server side.
krick 7y ago
They don't really have read from it, they may just use keydown event, for example.
zrm 7y ago
> I imagine it would stop you from client-side warnings of password insecurity, but is there a bigger problem? The bigger problem is that passwords aren't half the sensitive data on the web, they're just the example people are using because everybody knows they need to be protected. If you protect the password from the script but it can still read your name and address, and your bank balance, and the private information you thought you were only sending to your spouse, have we actually solved the problem? No.

by SilasX 7y ago

ceejayoz 7y ago

It would kill any site with an AJAX-based login. Twitter, AirBnb, Facebook, Google, Apple...

bmm6o 7y ago
Yeah, posting a form to login in is the exception nowadays.
chopin 7y ago
A good thing, imho.

noodlesUK 7y ago

I imagine it would be pretty easy for the js to just remove the element from the DOM and replace it with a similarly styled input if all we are doing is stopping it reading the contents of the password input

lucb1e 7y ago

I use JavaScript on some password fields for client-side password hashing (reasoning: https://security.stackexchange.com/a/201099/10863 https://security.stackexchange.com/a/201099/10863), but I agree that this might be a useful thing. I can think of a few ways this could work: - Blacklist or whitelist access: <input type=password nojs> or <input type=password allowjs> - Specifically set a method that is called upon form submission: <input type=password onsubmit=hashPassword> <script>function hashPassword(value){ ... }</script> The catch here is that the browser would have to error out on reassignment of the hashPassword global variable, since that is what malware would do. This sounds easy, but it might be quite a bit more complexity for the browser's JS engine, since it has to check every assignment in the global scope against a list of functions that are used for password fields. - Only allow access from the code path starting with the form's onsubmit event, so <form onsubmit="return validate(this)">. The catch here is that most modern websites do $("#myform").onsubmit=function(){...} which any malware could do as well, so that would have to be disallowed. A lot of devs wouldn't be happy about that. Though for backwards compatibility, the opt-in method would probably be the only candidate for actual implementation in the foreseeable future.

blacksmith_tb 7y ago
That's a tricky one, though - you're basically deciding for your users if their credentials will be at risk. As one of your users I'd rather make that call for myself...
- lucb1e 7y ago
  You're always making that call, either client or server side.

krick 7y ago

They don't really have read from it, they may just use keydown event, for example.

zrm 7y ago

> I imagine it would stop you from client-side warnings of password insecurity, but is there a bigger problem? The bigger problem is that passwords aren't half the sensitive data on the web, they're just the example people are using because everybody knows they need to be protected. If you protect the password from the script but it can still read your name and address, and your bank balance, and the private information you thought you were only sending to your spouse, have we actually solved the problem? No.