Re: Securing Password Inputs

> This isn't about securing them for transport, this is only how to store them in a way such that the effects of a breach are negligible, eliminating phishing and coming up with a more consistent password solution.


Like much of the HTML spec and the conversations on this list I think this conversation is trying to go in a couple directions at the same time and yielding typically wierd mishmash of ideas.

A "consistant" password solution is an oxymoron. If everybody is doing the same thing then you have simplified the problem space for a hacker. This is like asexual vs sexual reproduciton. asexual reproduction is more efficient but if a disease affects one organism it will wipe out all of them. Only by mixing things up and causing mutations and randomization do you have some hope of protection and longevity. 

Furhtermore, whatever you do, you don't want to encode it in an html page and/or javascript.  The reason why server side solutions are preferred is because it is significantly more complicated to look at the traffic,internals, or scripts on a server than it is in a client especially in the age of developer tools.

My point was that the time in need of protection is the point between data entry and submission. Because it is then that a password is vulnerable.

I honestly think the password stuff is more an OS keychain level problem than an HTML problem. I recommend you check out 1password or similar software as a model and recommend adapting the relationship between OS, browser, and server via whatever protocols are involved.

User agents can adopt some password protection schema, but ultimately if the passwords are retrievable by anything other than whatever is posting content to a server it doesn't matter what you do.

To be clear, I think the conversation is important. But it probably needs to be split into specific threads and distributed to appropriate lists.
 


Art C


On Aug 31, 2012, at 3:53 PM, Jason H wrote:

> This isn't about securing them for transport, this is only how to store them in a way such that the effects of a breach are negligible, eliminating phishing and coming up with a more consistent password solution.
> 
> 
> 
> 
> ----- Original Message -----
> From: Arthur Clifford <art@artspad.net>
> To: public-html-comments@w3.org
> Cc: 
> Sent: Friday, August 31, 2012 6:35 PM
> Subject: 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 23:42:21 UTC