> An analysis of the hacks by security biz Imperva reveals that most of the breaches were pulled off using SQL injection attacks.
Client-side encryption, even in JS, would have prevented this, it seems.
Client-side encryption, even in JS, would have prevented this, it seems.
If you depend on the client for your security => Game Over
(of course, SSL is kind of dependent on the client, but it's their security not yours in risk)
Endpoint encryption does solve many problems, but it doesn't solve all of them. Take a bank case: sure, you could encrypt your account number and transfer amount on your machine, but the how is the bank supposed to do anything with these random bytes you've sent? If they have the keys (like they do with SSL), we aren't any better off.
With some complex public key crypto, you could maybe make things better, but you would be dependent on everybody treating their private keys well. I'm not convinced big companies could manage that, much less "Joe the Plumber".
Trusting the client is not the same as securing the client.
Edit: I didn't like my initial tone, so I backed off.
How encrypting user data in JS on the client is different from properly hashing user passwords in JS on the client? It is now accepted that sending and storing passwords in plaintext is bad practice; the logical next step is to encrypt not only passwords, but all data on the client.