Properly hashing/salting passwords on the client (in JavaScript) is more or less a must now.
Client-side encryption is the next logical step. Although not perfect, it is better than storing plaintext data on the server.
235 karma · joined July 18, 2012
Client-side encryption is the next logical step. Although not perfect, it is better than storing plaintext data on the server.
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.
Client-side encryption, even in JS, would have prevented this, it seems.
I'm not against functional languages/approaches. I just think that everything has its place, and that procedural code and nested if/then/elses are appropriate in many circumstances.
This varies by the company, but many companies are full of self-important people like this.
The way Ben had intended to - by explaining things. He ended up pulling authority and threatening to fire everybody involved, for some reason.
You can have web interface with client-side encryption. Check aes.io (plug).
For example, Apple did not invent the personal computer or the smartphone, they just made these products actually useful for the masses. Microsoft's OSes were not that good for the first twenty years, and Microsoft Office was in no way a technological breakthrough, but MSDos/MSWindows + MSOffice did bring a PC revolution and a PC on (almost) every desk.
And in the long term those employers regret hiring such people:
> Rose also said that Digg hired individuals with very niche skills, like developers who only knew PHP and were not as useful once PHP went out of use. (from here: http://gigaom.com/2012/07/25/kevin-rose-reflects-on-digg-the...)
Envy-driven development is not a good model. Desktop environments do not need tablet features in the first place...
> This is possibly just a case of the vocal minority and normal resistance to change but it will be interesting to see it all shake out in a year or two.
Or the opposite can be true - a powerful minority (project/company leaders), envious of other companies' success on tablets, decided to spend a lot of resources to try to enter this space, to the detriment of the majority of their (desktop) users.
The article lists three reasons for why "JS crypto is bad" at the beginning:
- Secure delivery of Javascript to browsers is a chicken-egg problem. - Browser Javascript is hostile to cryptography. - The "view-source" transparency of Javascript is illusory.
The first issue is addressed by using SSL and controlling the page 100%. The third issue becomes a matter of trust, as many users trust closed-source vendors, so in an environment where closed-source vendors are truested (e.g. a typical accounting firm), the third issue becomes not about JS crypto but about vendor reliability.
That leaves the second issue. The article expands it as:
- The prevalence of content-controlled code. - The malleability of the Javascript runtime. - The lack of systems programming primitives needed to implement crypto. - The crushing weight of the installed base of users.
The first and second sub-issues, again, are more or less addressed by using SSL and controlling the page, I believe. One can argue that because JS is so "malleable", it is very easy to add malicious code to a page. Yes, it is easy if you have access to it (via third-party scripts/XSS), but it is _harder_ to infect a JS crypto page that is properly set up than a regular online-banking page, for example, as most online banking pages have links to third-party advertising (often over plain HTTP!). So in the world where people and companies do online banking, the "malleability" does not seem to add a lot of issues.
The third sub-issue is being addressed in HTML5 and/or, via SSL, round-trips to the server (for random seeding, for example).
The fourth issue is, again, not much different from online banking.
In summary, it seems we are using somewhat different criteria of what "secure JS crypto" means. You seem to be saying that storing data in aes.io is less secure than in a truecrypt volume. I agree 100%. But what I am saying is that for an accounting firm that does online banking on a daily basis, using aes.io as opposed to a cloud collaboration service without client-side encryption would probably be a great idea.
One is intentional leakage, or trusting the vendor to be "not evil". Here you are right - as you mentioned in another comment, there is no easy way for users to "police" the vendor of JS crypto. I do not see, however, how this is different from users trusting other vendors of auto-updating software.
You can probably argue that OSS pieces such as Linux and FF have this "policing" enabled through source code availability. But there are many closed-source vendors (Microsoft, Google, anti-virus vendors) that many users trust. If you don't trust the companies mentioned above, then yes, you should not trust aes.io and other JS-crypto based vendors. But if a user has Microsoft/Apple updates enabled, and browsers (other than FF) auto-updating on their systems, etc., then this becomes a question of vendor being "not evil", not weaknesses of JS crypto, and as such somewhat out of scope of scrictly "JS crypto - yes or no" discussion.
The second issue here are unintentional leaks and breaches. Read-only breaches, for example, become more or less non-issue with JS crypto, because stealing properly encrypted data is not that useful. And there are probably orders of magnitude more read-only breaches than read-write, simply because inside companies more people have read-only access to production data than read-write access. Thus JS crypto seems to help substantially reduce the risk of unintentional compromises.
The second issue needs more attention and discussion from the technical point of view, I agree, and I am open to it. The first issue, however, becomes "I trust this vendor but I don't trust that vendor", and this is not a discussion that I believe can be productive here and now.
And good luck with you app - client-side JS crypto needs more dev attention. :)
I've read the Matasano article, don't assume I didn't. Most of the points in it are negated by controlling the page 100% and using SSL.