1
edit
(Add option to setAttribute() with JavaScript) |
Highwayfive (talk | contribs) |
||
Line 18: | Line 18: | ||
In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]), or browsers like ELinks and OmniWeb that have form history and ignore the attribute entirely. And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants. | In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]), or browsers like ELinks and OmniWeb that have form history and ignore the attribute entirely. And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants. | ||
I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]). | I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS - Information on Cheque Clearing and Cheque Fraud ] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]). | ||
edit