Re: [whatwg] Hashing Passwords Client-side

2011-06-22 Thread Sean Connelly
Hi All, I believe there are three major discussions: 1. Is the security gain using client-side hashing worth the cost of implementation and education? 2. How would you implement client-side hashing? 3. How will incorrect deployment of client-side hashing affect security? I would like provide an

Re: [whatwg] Hashing Passwords Client-side

2011-06-22 Thread Mat Carey
On Mon, Jun 20, 2011 at 6:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side

Re: [whatwg] Hashing Passwords Client-side

2011-06-22 Thread Sean Connelly
Hi Mat, The legacy-browser user will in this example be asked to enter a password in a text input, not a password input... intentional or typo? Intentional for the demo (as marked after the field). I forgot to mention as well: The demo is not production-level code. It incorrectly handles

Re: [whatwg] Hashing Passwords Client-side

2011-06-20 Thread James Graham
On 06/17/2011 08:34 PM, Aryeh Gregor wrote: On Thu, Jun 16, 2011 at 5:39 PM, Daniel Chengdch...@chromium.org wrote: A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In

Re: [whatwg] Hashing Passwords Client-side

2011-06-20 Thread Nils Dagsson Moskopp
James Graham jgra...@opera.com schrieb am Mon, 20 Jun 2011 10:40:20 +0200: […] and the authors who are most likely to get the server-side wrong are the same ones who are already storing passwords in plain text. What reasoning is behind the assertion that those authors will use the provided

Re: [whatwg] Hashing Passwords Client-side

2011-06-20 Thread Tab Atkins Jr.
On Mon, Jun 20, 2011 at 11:15 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: James Graham jgra...@opera.com schrieb am Mon, 20 Jun 2011 10:40:20 +0200: […] and the authors who are most likely to get the server-side wrong are the same ones who are already storing passwords in

Re: [whatwg] Hashing Passwords Client-side

2011-06-20 Thread Aryeh Gregor
On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote: FWIW I disagree. The same argument could be used against client-side form validation since some authors might stop doing proper server-side validation. I agree, HTML5 forms provide a minor net security loss. However, the

Re: [whatwg] Hashing Passwords Client-side

2011-06-17 Thread Mat Carey
Sean, thanks for the suggestion. I have the following comments (my first comment on here, please instruct me if I get the style wrong): Why? The server can first try comparing the submitted password to the stored hash, then if that fails, hash the submitted password and compare that to

Re: [whatwg] Hashing Passwords Client-side

2011-06-17 Thread Sean Connelly
Hi Mat, The simple solution to your problem is: The server SHOULD still hash the password it receives, before storing it in the database (i.e., the client would send a hashed password, and the server would hash the hash). Ideally, all servers should be doing this, with per-user salts. However,

Re: [whatwg] Hashing Passwords Client-side

2011-06-17 Thread Mat Carey
Thanks Sean, The server SHOULD still hash the password it receives, before storing it in the database (i.e., the client would send a hashed password, and the server would hash the hash) I agree, but if the server-side hashing should be implemented regardless of whether the client-side

Re: [whatwg] Hashing Passwords Client-side

2011-06-17 Thread Aryeh Gregor
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng dch...@chromium.org wrote: A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In general, I feel like the same objections are

Re: [whatwg] Hashing Passwords Client-side

2011-06-17 Thread Sean Connelly
Thank you for your input. I had forgotten about the input type=image fields. Yes, as these issues have been brought up, I've also imagined additional disadvantages as well. For documentation purposes, here are some additional items to consider if this topic comes up again: 1. I'm not clear how

[whatwg] Hashing Passwords Client-side

2011-06-16 Thread Sean Connelly
Hi All, I've just joined the mailing list, and this is my first time in such an environment, so I apologize ahead of time if I'm not using the list correctly. I would like to propose an idea for inclusion in future generations of HTML, or at least, I am curious if such an idea has already been

Re: [whatwg] Hashing Passwords Client-side

2011-06-16 Thread Tab Atkins Jr.
On Thu, Jun 16, 2011 at 12:59 PM, Sean Connelly s...@pbwhere.com wrote: I've just joined the mailing list, and this is my first time in such an environment, so I apologize ahead of time if I'm not using the list correctly. Nope, you did pretty good. You listed a problem, and then proposed a

Re: [whatwg] Hashing Passwords Client-side

2011-06-16 Thread Aryeh Gregor
On Thu, Jun 16, 2011 at 3:59 PM, Sean Connelly s...@pbwhere.com wrote: ## Proposed Solution: Add an attribute to input type=password called hash.  For example: input type=password hash=sha1 salt=something How does this solve the problem? Do you expect it to help because users will be able to

Re: [whatwg] Hashing Passwords Client-side

2011-06-16 Thread Daniel Cheng
A variation of this idea has been proposed in the past but was largely seen as undesirable--see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In general, I feel like the same objections are still true of this proposal. Daniel On Thu, Jun 16, 2011 at 14:08, Tab Atkins