On 11/12/13 23:16, Cathal Garvey wrote:
With an average of 5 important sites and 50 less important site per person, it requires people to *remember* 55 totally different 20 character passwords.
If you could be assured of client-side salted-JS-hashing of the password prior to submitting it to the server, then you could in principal use the same password everywhere.
Who is providing the javascript? The site? The NSA? Then it can send a NIL-cipher that effectively transmits the single password in a recoverable way to the server. It would be unnoticable to the user.
This used to be the norm, but SSL made it easier first to store plains, and for (as the security concerns of break-ins became apparent) to store server-generated hashes. Yet many, perhaps most, services don't do their job correctly on the server-side. If it were still done client-side, a savvy user could make sure hashing were done correctly, and salted appropriately.
Don't assume people will do anything intelligent. Tehy won't! We should protect people even when they try to do stupid things. Security and privacy must be standard and be reliable to be trusted upon.
The world needs to forget passwords as remote identification and move on to client certificates. Preferably, a separate client certificate for each site. It takes only a small browser plug in to make it easy.
Ideally yes we'd all use unique certs for everything, but then we'd be tied to our particular browsers. You could make this work with a well-implemented browser sync agent, but what about users of pathetic platforms that don't support trustworthy browsers (iPhone, Nokia)?
You hit the nail on the head. A reliable syncing agent provides the seamless user experience and protects against a loss of a private key (that's needed to prove ownership of the certificate). Browsers that don't support this syncing will find themselves as roadkill of the ubiquitous encryption age. They will adapt or die. Regards, Guido.