Link Details

Pointless, just use SSL and one way encryption with random salt server side.

antych,

Many sites probably employ SSL, but SSL has its shortcomings as well. You still have to trust web developers to use one-way encryption in their database, but my experience proves many don't. I've received account confirmations with clear-text passwords countless times.

One other tell-tale is that the site's "forgot password" feature actually mails you your current password instead of generating a new one or a one-time change password link. This has also happened to me several times.

My suggested solution is client side. Therefore you do not need to trust the web developers to store the password securely -- you can check the scheme they employ in the HTML code.

It is also very non-intrusive to the rest of the web application, since the hashed password could be treated just like the regular password. For may webapps you would only have to change the HTML for the login page and the database table storing the password (to ensure that it has enough room for the SHA256 string).

If those developers don't know how to store passwords, what makes you think they will read your blog and implement this idea?
You suggested a new technical solution for incompetent people who don't know an already existing, proved and widely used one. Can you see how your logic is flawed?

I think you miss my point. My solution increases security without any other change than the login HTML page and one database column definition. Adding SSL or encryption in the database access code requires significant changes to the web application.

SSL also adds cost and complexity in form of certificate issuing costs, certificate renewals and private key storage.

He explains the vulnerabilities -- and they are major ones. Better to try an RSA-type encryption strategy for authentication, though a bit more comlicated.

xcdesz,

How would you envision an RSA-type scheme? One key pair for each user account? Where should the key pairs be stored?

SSL has supported this for ages -- client-side certificates -- but hardly anyone uses them. The main reason for this is certificate and key distribution and management. It's hard to do right.

I considered using RSA for my solution as well, but decided on SHA256 for simplicity. An RSA-based solution would require a public key stored in JavaScript and a JavaScript RSA implementation. The benefits for this solution has to be weighed against increased complexity and reduced performance.