[whatwg] <input type="password">... restrict reading value from JS?

?ann m?n  1.?g? 2011 15:25, skrifa?i Aryeh Gregor:
> If you're doing useful password strength checks, regular expressions
> won't cut it.  For instance, you'll want to check against
> dictionaries.  Regex is only useful for crude and ineffective checks
> like "must be at least six characters long with mixed-case letters,
> numbers, and punctuation" (= "Abcd0!" is okay,
> "effervescentarcheopteryxattack" is not).
>
My point is that a sites aren't going to distribute JavaScripts that 
fetch a cracklib dictionary and look the password up in it. A cracklib 
may be available to the user agent, in which case the UA can look the 
typed in password up. Unfortunately, the UA probably won't know if the 
password is input for registration or login, but that can be worked 
around with "Don't warn me again" buttons on the passive warnings. And 
even if you want to allow authors to recommend dictionaries, doing so on 
as high level as possible (i.e. declaratively) simplifies caching, 
especially important where a cache miss will be an exception.

> JavaScript acts as the agent of the receiving server.  This is a
> cornerstone of the web security model.  The server is what sent you
> the JavaScript, so it's trusted to act on behalf of the site.  There's
> no way you're going to paper this over by trying to remove one or two
> minor privileges from JavaScript.  (Yes, there are a few cases where
> we do this as an XSS defense-in-depth measure, like HttpOnly cookies,
> but only for very narrow things where it makes sense.)
>
Indeed.

>> This is one of the reasons some people disable
>> JavaScript. Most don't, as they don't want to stop JavaScripts from
>> doing other more useful things. If we disable just stuff like this we
>> can bring some security to the folks that have JavaScript enabled
>> (such as me).
>
> No you can't.  JavaScript can replace arbitrary page content.  You
> can't work around that without crippling it.
>
As I suspected.

>> Are XHR submits of passwords common and important enough to outweigh
>> the security cost of scripts having access to all passwords in their
>> document(s)?
>
> Yes.  We can't stop them without breaking the web.
>
>> I propose disallowing changing the action attribute of forms with
>> password inputs.
>
> We can't do that without breaking the web.  There are going to be
> countless sites that rely on being able to create forms in JavaScript,
> which includes setting their action attribute and includes forms with
> password inputs.
Ok. I'll use HTTP authentication methods or HTML login forms in a 
dedicated document (linked to with sandboxing where applicable).

Received on Monday, 1 August 2011 19:56:51 UTC