Re: Securing Password Inputs

While I think that securing password iinputs is a good idea in principal I don't think it is an HTML problem it is more a browser problem.

Passwords should never be sent in plain text, and should be sent via SSL so that the transfer is encrypted. The problem then is how is the password stored in memory having been entered and prior to transfer to the server.

It would be nice if the browser did encrypt password fields in some 2-way encryption scheme so that the browser could decrypt it prior to sending it via ssl to the server. However, I would not broadcast what encryption it is using by including anything in HTML which anybody can read by viewing source or using the developer tools now in every browser.

I would also not have any hashing or any other encryption algorithm in JavaScript for the same reason. Anything done client side is painfully visible.

The only way protecting the password fields through any new algorithm would be reliable is if a) the user-agents do not use one but multiple undocumented encryption routines and choose which to use by some super secret algorithm that changes with some regularity perhaps between browser updates. b) it becomes impossible for js, plugin, or other non browser-developer to have programmatic or developer tool access to the password input fields.

In fact, there may be justification for something called a SecureForm in which case all inputs are locally encrypted and completely unavailable to anything other than an ssl stream during a post to a target script.  If the HTML 5 spec included such a form then it should not specify the encyrption method but rather suggest it is up to the user-agents to provide encryption and perhaps recommend some good practices.  It would also suggest something like a noscript tag, perhaps nosecureform ,that would allow you to put up a message saying that your page requires an HTML 5 browser for security purposes thus addressing people who insist on using IE 6. 

Any other solution seems convoluted and absurd and too in-plain-sight to be viable.

Art C

Received on Friday, 31 August 2012 22:36:14 UTC