Stanford Javascript Crypto Library
crypto.stanford.edu
crypto.stanford.edu
WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.
SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.
Combine this with HTTPS and I think doing the crypto on the client is certainly feasible (and has been implemented by mega (well, they messed up a few things, but that was an issue in their use of crypto, not the crypto implementation) and 0bin).
EDIT: Also, the site you are quoting is explicitly complaining about people using JavaScript security but NOT over HTTPs, and they claim that there is no advantage to using JavaScript crypto when you are using TLS anyways. This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/
Verified by who?
TLS doesn't protect you against a malicious site that is collecting passwords. Even if you were to examine the javascript code to verify that it isn't sending the plaintext[1], they could send a different chunk of code any time you access the site in the future. Either because the site is malicious -- as in the above example -- or because it has been compromised (whether that be by skiddies or three letter agencies with legal papers).
The only 'benefit' javascript crypto gives you is that it makes it easier for people to develop apps where the users data is encrypted before it is sent to the server (such that the server can never decrypt it). However doing this in a javascript web app totally negates that since the server can just send a compromised chunk of js any time it feels like. So the additional security to the user is basically zero.
If you want to seriously create a service like this don't use javascript inside the browser. Do what Tarsnap does: provide an open source native client that does not automatically update.
[1] and let's not pretend that modern javascript is at all readable, in the age of minification and asm.js
[0]. https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...
I struggle to see what the point of it is[2]. You are already (hopefully) sending all the user data securely over the wire. In a current app the user needs to trust the server with their plain text data. With a js crypto app the users needs to trust the server to provide the crypto code to encrypt their plain text. Either way the user has to trust the server and once the server is compromised their data is trivially retrievable. At best it would prevent your data being seen until you login. If all you are interested in is data storage that is secure because nobody ever retrieves the data then I can offer you a great price on such a service.
[1] http://cm.bell-labs.com/who/ken/trust.html
[2] other than attempts to provide plausible deniability for legal reasons
A piece of hardware, with an embedded linux machine and wifi capabilities – intended as a piece of consumer electronics(1) – with the main user interface being an HTML5 webapp intended to run on a phone(/tablet/computer). The hardware will either boot up and establish a wifi access point that you connect your phone to, or you'll be able to configure it to connect to your home(/office/shop/venue) wifi network where it'll (typically) live behind your NAT gateway on a 10...* or 192.168.. network. In either of those two configurations, it's difficult to ensure TLS secured communication between the phone and the hardware – where by "difficult" I mean "without big scarey 'YOURE ABOUT TO CONNECT TO AN UNTRUSTED SERVER' warnings baked into browsers when they hit TLS certs without proper root-CA-trusted signatures, for a bit of inexpensive consumer electronics aimed at your Mom or grandparents - accepting self-signed certs or installing self generated trusted keys is a difficult UX problem, and buying real trusted-CA-signed certs for production runs of 10,000 is expensive (and it's impossible to then secure those private keys against anyone with a screwdriver).
I'm currently deciding between relying on WPA2 encryption and forbidding access to things requiring sensitive data (passwords) if the wifi isn't encrypted, or using a modified version of OAuth2 and relying on a cloud service that I can TLS secure with a CA-signed cert (OAuth2 assumes you'll TLS secure all the redirects, but I can't use TLS for the phone/hardware segment as described above. I've got an "I hope not too screwball" workaround involving generating public/private keys on the hardware, sending the public key to the cloud server, doing the OAuth there, and instead of sending the auth token back over a TLS secured channel, encrypt it to the public key first then send it over regular old http). I'm now wondering is JS crypto might solve that part of my problem…
(1) in my case, intelligent Christmas tree lights – http://holiday.moorescloud.com for the curious, and http://dev.moorescloud.com for the (open sourced) hardware and software details.
A further incremental improvement could be made using a Mega-style root of trust (ironically, an article explaining how they messed up the implementation explains it best: http://fail0verflow.com/blog/2013/megafail.html). Only the initial loader page (with embedded hashes and MACs) needs to be checked for whether or not it has changed on each page load. If you want to be immune from a later malicious update, you just have to manually save the loader page and open it instead of re-requesting it from the Mega. Yes, during an update they can stop serving the old scripts and deny access, but you will at least always know when an update has occurred.
browsers are being patched for a long time now.. to fit into sophisticated models.. it came all over here, by using duct tape.. but now it can be patched anymore to get into the next level.. it cant reach the next level because its broken by design.
how long until people face the reality?
The biggest problem with getting users to adopt crypto is giving them stepping stones to something better, and giving them subtle explanations of risks with lesser involved approaches. I understand the fear of giving the user a false sense of security. We should try to mitigate doing so, while still giving a path to adopt best crypto practices over time. Wholesale adoption of crypto by society is only going to happen when people promoting crypto realize that crypto, like everything else competing for the attention of users has a conversion funnel.
The problem is JavaScript.
There's parts of their post that I don't like:
"If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code." "How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL."
I wonder about the implicit threat model. Its too black-and-white for me. In it, you either trust the server or you don't.
But security and privacy, for me, for large numbers of users, is all tradeoffs and games, shades of grey.
Consider: maybe our computers are uploading the private files of everyone who runs Windows to Microsoft. I don't know for sure, but I'd gamble that they aren't. I don't think MS would they take the risk of some security researcher catching the anomalous traffic on the network. The threat of the resulting PR storm would help keep MS honest, at that scale. So I'd expect MS would try pretty hard to fight a government leaning on them to do that.
Lets say that, in future, all data on the worlds most popular social network is encrypted client side. My ID is just a public key, and my browser encrypts all my traffic, using a JS package the social network securely delivers me. (Over SSL. With great care.)
That'd be a similar scenario to MS. I'd be trusting them when I enter my password into the JS they sent me, that is running in my browser. But, again, I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone, probably some security researcher would call them on it. And so, they'd be incentivised not to.
That's a fundamentally different situation to the current one, where if Facebook gives all our data away, its pretty hard for someone outside their organisation to find out. Probably they could gamble on keeping it secret.
So that's why I think the 'Javascript Considered Harmful' post is too strong, in its "you either trust the server or you don't" attitude.
I also think that we aren't going to get anyone using crypto, unless its delivered seamlessly in the browser. There has been good crypto available for years (e.g. GPG on the deskop plugged into thunderbird). But I think we've learned that if its even slightly harder to use, then end users are going to ignore it.
And the way to deliver seamless ease-of-use to a wide audience is on the web. And we badly need easy-to-use privacy these days. So I think it'd be a shame if posts like that discouraged research into JS crypto.
(I can think of other arguments:
e.g. where you want to trust a server now (e.g. to encrypt and backup a document) but decide not to trust it later (decide to abandon the document because in the years since you uploaded it, you think the server/company is compromised - or you ask to be e-mailed the ciphertext)
or regulatory differences: I don't think its the same thing legally to demand or steal a copy of someones server side data, and any server side keys, as it is to demand that the javascript be changed to snoop future passwords as users enter them into their browser application?)
Again, I'm no expert in this area; corrections welcome.
"...I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone..."
To everyone — maybe that would get found out, maybe it wouldn't. But it doesn't have to be done to everyone. That backdoor in the JS could be served to only you. Maybe only certain times of day. How are you going to know?
I'm just saying that there are situations where JS crypto might be useful, such as increasing the difficulty of conducting mass surveillance in secret.
Secret mass surveillance being, of course, a big topic recently.
What people need is not security that defends perfectly against every threat in theory, but no one uses in practice.
Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server.
For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves up the client-side app) is hacked and the client-side application is modified to send your private keys back to the hacked server, there is currently no way you'd know as the consumer of that client-side application. If signed JavaScript existed, then browsers could alert you that the JavaScript that you're running has been modified and doesn't match the signature, so it refuses to execute it.
Security is achieved through layers. No single layer can protect you from everything, but we lay down the gauntlet in the hopes that an attacker will encounter a road block that they cannot pass.
HTTPS says, "The communications you send to the server cannot be intercepted and changed between the client and server, and the identity of the server you're connecting to has been verified by one of your trusted certificate authorities."
HTTPS promises that your communications cannot be snooped on, and the person you're talking to is verified by a mutually agreed upon third-party.
Code signing does something entirely different. Code signing says, "The code you're about to run was written by the developer specified in the signing certificate, and has not been modified since it was signed. The identity of the developer has been verified by one of your trusted certificate authorities."
So the practical difference is this:
Say your browser requests https://domain.com/random.js. HTTP ensures that you're connecting to domain.com, and that your communications won't be changed or observed in transit. However, it does not guarantee that some malicious third-party didn't overwrite random.js on the server. With code signing, you can accomplish that. An author can "sign" a code package so that any alterations to the code itself would cause a certificate invalidation.
Suppose we sign https://server.com/sjcl.js. That resource is now tamper-proof in the event that server.com is compromised. But what about the rest of the application HTML/js? For example, an attacker could just say:
<script src="/sjcl.js"></script>
<script>sjcl = ...</script>
Ok, suppose the browser support for content-signing prevents this somehow. The attacker can still modify the application-level code to use the library unsafely. I'm not totally familiar with the API sjcl exposes, but consider something like the e=1 RSA bug that was found recently.
Even if sjcl's API is so great that it's impossible to misuse, an attacker could simply render application code that doesn't use it at all. Or he could just log keystrokes and phone home the pre-encryption content.
What if we sign everything, including application HTML/js? Now we have another problem. We've basically resigned ourselves to serving only static content. We can't render any user input, because this would require a new signature. Probably not a useful web app.
EDIT: so..if you had a single page web app, signed or even checksum'd the whole hunk in a known good state, couldn't you then trust the execution of the app? Further if you had an external service (as I propose in a comment below) that validated the signature/checksum couldn't you then trust the whole package?
<script src="scriptloader.js"></script>
<script src="jquery.min.js" data-md5="a1b2..."></script>
This protects against any external scripts being unexpectedly modified, e.g. someone MITM your jquery source.
Oh, also, those scripts can themselves load in other scripts you haven't checksummed.
This is madness you're suggesting.
Because you might be using a CDN for performance and bandwidth benefits.
If you relying on a third party piece of code that you allow to change at any time, then it is very difficult to do any release testing to give you a known set of conditions your application should work under.
How is checking the validity of the scripts that run on your site madness??
1) load your loader script, which has the URLs, fingerprints of the scripts you want to run, and the necessary dependency information (jquery-ui must load after jquery for example). In the best case, this file is being served out by the same server that's hosting the HTML, that way at least you're not adding more attack vectors.
2) from the loader script, initiate ajax requests for each of the remote files you need
3) as you get each one back, validate that its signature matches those that are expected, raise an exception if it does not (ideally also displaying something to the user), and evaluating it if its signature matches and we've loaded all of its dependencies.
So, why is this madness?
1) Most of the time the reason that you're letting a third party host these files is for speed. They've got a CDN, and hopefully the file will already be cached by your user. Grabbing resources with javascript that you could load directly in the html will slow down your page's loading time, as the browser's html parser isn't able to look ahead and fetch resources that are likely to be needed before the renderer has asked (HTML has a defined rendering order that can be kinda strict sometimes, this is the same reason why you don't put your <script> elements in the <head>).
2) Another reason for using a CDN for your JS libraries is convenience, which this process also wipes out.
3) The whole thing won't work at all unless the third party server sends back cooperative CORS headers, as you can't do an ajax request to a third party site without their cooperation.
Finally though – and this is the big one – it's more convenient for the developers, strictly safer, and faster for the end user if you just compile all of the JS and serve from the same domain that's serving your HTML. As stated above, if that server is compromised, you're toast anyways (barring a browser extension or similar). If you really want some more security, look into SSL (and actually look into it, there's definitely much better and much worse ways of doing it).
The one possible catch, as you mention, would be getting access to these scripts before they are loaded without having cross-origin problems.
There are a number of problems with serving from your own domain. It is, in fact, much less convenient for developers, as it adds an extra step to the build process and requires the system to properly handle caching so that old resources are not still served after a build. It is also slower to serve from the same domain as there are connection limits. Lastly, it gives up all advantages of a CDN.
My proposal is an attempt to continue taking advantage of CDNs and third party resources, but without giving them the keys to your site. Did you ever consider that Google has access to all of your users' cookies, if they wanted to add a small modification to jQuery or Analytics? Considering recent revelations about government involvement, is it really out of the question to believe that they never would take that information?
I'll try to extract the core of my argument. The hashing proposal is madness for two reasons: 1) it's slower and less secure than just serving all of your js in one file; 2) it will not actually work without the cooperation of a CDN.
1) The proposal requires you to have one trusted server that you're serving javascript resources out of (because you need to load the script loader and fingerprints from there). If you want fast and secure, you've already paid the cost of a round trip to server #1, and the risk of trusting server #1. The sane thing to do from a performance and security standpoint is to load all of the javascript that you can in that request. Otherwise you're going to be blocking on that request returning, then the renderer reaching that script's location in the html, then that script being executed before it fires off the requests.
2) I'll phrase this as a challenge. Try to load jquery from a CDN with an ajax request. Remember, the key is to get the source of the script into memory without executing it, so that you can hash and validate it first. Feel free to try it right now in your developer console, I'll even give you a code snippet to start from:
url = '//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js'
var request = new XMLHttpRequest();
request.open('GET', url);
request.send();The protections against malicious code have to be there, so it would be the same order-of-magnitude of installing any other browser plugin.
Here's some explanation from the website FAQ:
#### Browser extension
Our browser extension provides improved security by verifying the integrity
of the files served by the server. The verification is done using two factors:
- **Cold storage signature verification:**
In addition to SSL, static files (html/css/javascript)
are signed using standard Bitcoin message signatures on an offline machine
(the private key was created on that machine, and has no other copies)
and appended to the response body as a comment.
- **Comparing against the code on GitHub repository:**
The source code from the GitHub repository is built on Travis-CI,
and the resulting hashes are published publicly on Travis's job page.
The extension compares the web server response against those hashes.
If a potential attacker gains control over the web server, he still only has
access to information the web server already has (which is very little).
To get sensitive information, he would have to modify the client-side code
to send back more data to the server.
For an attacker to succesfully mount such an attack against someone with the
browser extension, he would have to:
1. Gain access to the web server
1. Gain access to the personal computer of a developer with commit access
to the Github repository
1. Commit his changes to the public GitHub repository, where they
can be seen by anyone
1. Gain **physical access** to the offline machine with the private key
For users without the extension, he would only have to do the first step.
It is highly recommended to install the extension.
<a class="btn btn-primary" href="TODO">Install extension</a>
#### Public key verification
To prevent an attacker from modifying our published Bitcoin public key,
its permanently embedded into Bitcoin blockchain in a way that is
[nearly impossible](https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power)
to modify (and becomes exponentially more difficult as time goes by).
The public key can be verified by taking the following procedure:
1. Take the SHA256 of the domain name ("****.com")
2. Create a Bitcoin address using that hash as the private key
3. Find the **first** transaction with that address as its *output address*
4. The *input address* of that transaction is our public key
If its ever required to change the public key, the announcement
will be signed with the old public key.http://www.w3.org/TR/WebCryptoAPI/
Netflix, of all people, have implemented a flavour of this at least once for Chrome:
I very much do not trust certificate authorities, but observe that you don't have to trust certificate authorities to make the security architecture of TLS work. Already, CA compromises have a minimized impact on properties like Google Mail, whose certificates are pinned in Chrome and Firefox. Soon, all properties will get the same privilege, when we adopt schemes like TACK that allow dynamic certificate pinning.
As soon as a critical mass of browsers support dynamic pinning, it will become drastically less profitable to target CAs, because attempts to present forged certificates to Internet users en masse will quickly be detected.
What "pre-shared key" are you referring to in SRP? The only a priori value needed for SRP is the safe prime (N) and generator (g).
On mobile, this random number generator is unfortunately not available on Android's browser, although it is available on Chrome for Android, Firefox Mobile, and Safari on iOS and up.
There's also a full browser-based Crypography API in the works. You can see the draft here: http://www.w3.org/TR/WebCryptoAPI/
Once all of this is implemented, the chicken and egg problem is solved, since the browser will then have native crypto primitives available. At that point, the main argument I see against browser-based crypto in JavaScript is the malleability of the Javascript runtime. And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP.
> And if you believe that's an intractable problem, then you should probably reconsider the use of any language for crypto that can be monkey-patched, including common server-side languages like Python, Ruby, and to a certain extent PHP.
Someone else in this thread mentioned http://www.defensivejs.com/ and I think it is going in the right direction.
Also, a homepage with a pitch, a visually appealing design, etc would likely generate some buzz from people who aren't interested in using it but are interested in the concept. This could very well lead to discovery by developers who would otherwise have never found it.
https://en.wikipedia.org/wiki/Mega_(website)#Data_encryption
EDIT: to spell this out, you would, self host the stanford library, for example, and have this service verify it against a known good checksum.
I know that creates a big pain in the ass in terms of modifying the page and in terms of making the page dynamic, but bracketing those two concerns -- why wouldn't that work?
Also, some browsers will run JS from urls referenced in img tags as long as they are served with a text/javascript MIME type.
It's far too big an attack surface.
If anyone is curious, it works just fine with BouncyCastle and RFC2989DeriveBytes (for PBKDF2).
Observe that SJCL's own authors warn about this problem.