Question

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?

Answer 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.)