In general you are right, however the security minded people are absent in application programming. Are these the same people who developed HTTP Auth:BASIC?
What we're talking about here isn't JS validation or parameter sanitation, it is merely that whatever password inputs you get will be pre-hashed. It is opaque to the server and application for the most part. The only issue are services that supply a new password during password reset. In these situations, a reset link is even easier, or the application can be modified to accept the double-hashed version of the password. Currently, these passwords are sent in plain text and stored in plain text or unsalted hash. ________________________________ From: Seth Call <[email protected]> To: Jason H <[email protected]> Cc: Cameron Jones <[email protected]>; Arthur Clifford <[email protected]>; "[email protected]" <[email protected]> Sent: Friday, August 31, 2012 11:02 AM Subject: Re: Securing Password Inputs There is no such thing as moving security to the browser, because it is a client-side application. If you disagree, OK, go right ahead... but this is a server-side mindset and I'd assert you will never, ever win that argument with security-minded folks. If you want to make it easy to implement server-side code, then by all means contribute to bcrypt (or other good password encryption technology), or language/framework adoption of it. But in the context of HTML5 and browsers, I can only recommend: Make end users aware of the importance of passwords. This is the basis of my suggestion, earlier in the thread, on making a standardized way to give users feedback on the strength of their password. On Fri, Aug 31, 2012 at 9:49 AM, Jason H <[email protected]> wrote: They might be cagey, but they are completely absent in implementation in the storage routines of user credentials for most sites. > > >Moving security to the browser is much easier because there are less browsers >than applications. > > > > >________________________________ > From: Cameron Jones <[email protected]> > >> The problem with specifying how to encrypt things in a public specification > >> is that everybody knows how it is done, and therefore all you are doing is >> resetting the timer for hackers to figure things out. There should be >> something provided by servers that the server knows and trusts. > >Exactly. There is a reason why security folks are cagey. > > >
