Is javascripts access to a password fields value c

问题:

If it is good style and security to store passwords securely and properly, then shouldn't the same be for web pages that require a user to enter a password?

consider this example

<script>

function copy() {
    var text = document.getElementsById('text');
    var pass = document.getElementsById('pass');

    text.value = pass.value;
}

</script>

<input type=text id=text>
<input type=password id=pass>

<button onclick="copy();">copy</button>

type something into the password box and click the copy button and voila, it is exposed to the world. However if you copy and paste from the password box then you will get useless data.

Consider the number of pieces of javascript that are included on your login page that are not controlled by you (analytics, pageflow trackers, hosted scripts in the cloud). Does it make sense for a web browser to prevent this sort of programmatic access to password fields and instead provide it's own password validation API?

回答1:

This vulnerability is intrinsic to the [traditional implementation of] application level authentication, whereby the login/password pair has to be collected and transmitted over the wire. (And the web browser is not the only place where this secret is threatened).

A few safeguards at the level of the javascript hosts and/or of http are in place to prevent some of the danger you foresee, but anyway there's always the risk of code injection...

The bottom line is that if effective security is required you may consider alternative authentication methods, such as OS integrated security, other forms of challenge-based security, and also non-password based approaches (eg: captcha-like challenges showing series of photos, some of which are pre-learned by the person being authenticated.)

回答2:

Does it make sense for a web browser to prevent this sort of programmatic access to password fields and instead provide it's own password validation API?

No. <input type="password"> is a convenience feature to not show text while you're typing it. It is not intended as any kind of security measure.

Everything inside the browser window is completely controlled by the web site. It could easily fake a password field, or sniff keypresses in the window, to circumvent any possible protection of .value for password fields. There is no way to reign this is, so there would be no point trying to disallow access to password fields.

What's more this would break several very useful features of password fields, like being able to have client-side-script check that you've typed a non-trivial password when signing up (and warn you about eg. using the same password as your username), or having a login system based on the client-side script hashing a password before sending it.

Consider the number of pieces of javascript that are included on your login page that are not controlled by you (analytics, pageflow trackers, hosted scripts in the cloud).

0, unless you're totally doing it wrong. You need to stop that.

Any script you include on your page has complete access to script your entire site. Hiding a typed password from a rogue script executing in your security context is utterly fruitless given that it could, say, drop an iframe into the document's innerHTML with the delete-account form in it, then fake a click on the submit button. Or log every keypress you make on the site.

If you include someone else's script on your page you are effectively giving them admin access, so you have better trust them. To put a tracker or advertising script on a site that has anything sensitive on it at all is an act of pathological optimism.

Yes, Stack Overflow includes a script from google-analytics.com. And yes, Google could, if they wanted to, include code in that script to make everyone edit all their answers to say “i like bottoms lol”, or make the admins delete everything. Maybe they won't, if they're in a good mood today. Are you feeling lucky?

---

i like bottoms lol

回答3:

It wouldn't make any difference to have a validation API, since any malicious JavaScript in the page could simply listen to keystrokes and log the password as you type it into the field.

Online banking sites sometimes have interesting password mechanisms, such as asking for 2nd and the 7th character of your password to be entered via a select box (which makes it harder to capture).

Ultimately, it's the responsibility of the web developer to make sure that all privileged code (e.g. JavaScript in the document) is secure. It's the same when installing browser extensions, Greasemonkey scripts or desktop applications - you have to check it's from a trusted source.

You might want to use OpenID instead of a password field (as with StackOverflow itself). Not only is it one less password for the user to remember, but it also delegates security to a more specialised identity broker, which hopefully has the tightest security possible.

回答4:

Consider the number of pieces of javascript that are included on your login page that are not controlled by you.

Why would you let anyone put JS on your login page that is not controlled by you?

You shoul have control over what is on your login page, so there is no reason the browser should intervene.

回答5:

Cross domain JS access is already prohibited so that scripts outside of the domain of the login page have no access to your password field.

回答6:

It's an interesting point but I feel that is the security of your web site is such that this becomes an issue then you won't be including any javascript that is outside of your control.

While I think that browsers providing a password validation API is a good idea, regardless of how you approach it, at some point some code outside your control, javascript or otherwise, is going to have access to the unencrypted password text. Where do you draw the line?

回答7:

So we're supposed to prevent the client from writing javascript that exposes their own passwords? I don't see the problem here.

What would you do for web developers who want to be able to access the contents of a password field? It needs to be accessible.