Slashdot Mirror
MIT Researchers Create Platform To Build Secure Web Apps That Never Leak Data
rjmarvin writes: "Researchers in the MIT Computer Science and Artificial Intelligence Laboratory have developed a platform for building secure web applications and services that never decrypt or leak data. MIT researcher Raluca Ada Popa, who previously worked on the Google and SAP-adopted CryptoDB, and her team, have put a longstanding philosophy into practice: to never store unencrypted data on servers. They've redesigned the entire approach to securing online data by creating Mylar, which builds and updates applications to keep data secure from server breaches with constant encryption during storage, only decrypting the data in the user's browser. Integrated with the open-source Meteor framework, a Mylar prototype has already secured six applications by changing only 35 lines of code."
I feel like this is what they all said.
How can you search or sort data and present it to a user when the data is encrypted? So you lose the sql storage which is essential for a web application imho.
nosig today
I've implemented a similar solution for one of my web apps.
It encrypts the data in the client with a password that they provide before it gets sent to the server. The client also decrypts the value when it receives it from the server.
The password is kept in LocalStorage (a feature of HTML5) so that it is never transmitted to the server.
Assuming the client application is not compromised, this is a great way to keep data secret even from the service operator.
Unfortunately, you won't see this scheme implemented in many apps because almost everyone's business model these days is all about scraping your data for use by advertisers.
Stick to HTML & CSS.
/dev/null ?
Once decrypted, the data can be snooped on. If data can be decrypted in the browser, then the browser has everything that's necessary to decrypt it. If "Everything that's necessary to decrypt it" is provided by the server, then leaking is still possible. Browser-side decryption also makes this sound like a Javascript solution, which also means the site is potentially open to cross-site scripting attacks - if the application is not properly secured against that (and 35 lines of code hardly implies that it is), it all comes tumbling down.
If the owners can decrypt then so can somebody else. The whole notion that encryption in itself is some sort of protection is a nonsense. There will always be a weak point and that is what will cause a data leak. You can encrypt till the cows come home but I can install a simple keylogger into your keyboard and your data is all mine.
Did something like this in 2005, with the data encrypted on the client side using the user's public key. The key pair is in a hardware USB token.
We also did something with this scheme for an electronic patient record project. Each doctor was issued a USB key with his/her own key pair, and when the doctor submitted any prescription to the system, the data were signed with his key, and the operation was logged into a central log database, each log record is linked to some previous log records in a Merkle tree so that we could detect if a log record has been tampered with or removed.
However, cryptography is hard to get right in applications, and clients are not willing to pay for it. Se stopped doing this after a while.
Yes. At last someone don't spouting the nonsense of "we are SSL, therefore we are secure".
Only decrypting user-side is most definitely the right thing to do.
But then... browser? The most secure and verifiable piece of software out there? Yeah, fucking-right.
So, this is all well and good for really simple sites but what about larger, more complex sites that require server-side processing of data that, as I understand it, will only be available unencrypted to the client? Does this mean you need to expose your business logic on the client-side? This does not seem very secure to me no matter what promises they make about being able to detect client-side tampering...
Also, with regards to "searchable encryption", can this be applied to real search tools like Solr or ElasticSearch?
So basically this is PGP, it's pgp for the web, but ultimately still PGP. How is this even remotely newsworthy? PGP is 23 years old, throwing it up on the web then calling what you are offering a "web service" is a joke. Real web services actually offer you know, services, beyond simple data retrieval, and I saw nothing in the paper that would allow for instance a server to scan a database table with user information in it in order to present the data in a useful fashion, or for the data to be useful at all beyond a pgp-encrypted file sharing/email service.
Monstar L
***** Hard to see how to avoid the hushmail scenario ***** http://www.wired.com/threatlev... ***** http://www.wired.com/threatlev... ***** https://www.hushmail.com/about... ("But I thought the data was always encrypted") *****
http://stephan.sugarmotor.org
"You don't notice any difference" -- So how do I notice that cleartext only ever exists in a sandbox? How do I notice that the Javascript they serve me is secure, if I'm not to trust the server? All a malicious server or a PRISM operator has to do is inject a little backdoor script. Encryption in the browser can never be safe unless it is browser-native and has an unmistakeable UI, and then you still need to trust your browser completely. The fact that Mozilla supports DRM now means that soon I can't even trust Firefox without any addons.
Eventually the data has to be rendered and presented for use by the application user. I'll just screen-scrape, thanks.
--Russian hacker
I want to delete my account but Slashdot doesn't allow it.
Am I the only one who read the read the article?
The Mylar system supports searching of the encrypted data and encryption with multiple, separate keys allowing multiple users to have access to specific records without requiring any key sharing.
The server can operate in a completely compromised fashion (in theory), as the data is all encrypted on the client side, before it goes to the server, and the server will never have the plaintext or the key to decrypt the ciphertext.
They seems to be operating under the assumption that it is much harder to compromise all the clients than a single server...unfortunately I don't think that claim holds up as there is nothing to prevent compromise of the clients if the server is compromised, via simple XSS-like attacks, which will be trivial since it will be same-origin.
IMHO, the only way to make something like this really work, would be hardened browser clients, with special encryption APIs which cannot be directly accessed by code that the server can inject (NOT JavaScript).
A lot of solutions exist to prevent leaking the data. The problem is many of them are difficult to apply, expensive to apply and not respected by the "users"..
However, even if we assume that this solution works good and is applied still users have to respect the policy. The problem occurs when a user is abusing his rights, that is an issue of data misuses that might lead to data leakages and cannot be prevented easily. (and this is a real scenario according to numerous studies and whitepapers around the web). So, how are we going to deal with it.
For now, all I just see is the proposal of systems that might not be applied in practice. Information flow exists for a while, usually tied with some access control system, and it can be reinforced with crypto and strong authentication. Moreover, typical inspection mechanisms can prevent trivial data leakages. So, the problem is not solved at all as noone really applies correctly all this stuff (or the users find them to hard to work with in everyday life). Moreover, data misuse and data leakage issue is not yet solved (even when applying all this technologies) in its core.
Moreover, there already exist a version of firefox that does some informatio flow control. (preventing information leakage) It is not really good but the idea is here...
I am really sorry MIT but it is not going to work and it is not a solutions that aims at the core of the problem.
It's a few days early for the April Fools edition of Slashdot. I'm sure the MIT researchers in question think they really have something here but it would be nice if they would've looked around before beginning their research. It seems as though this system connects to a server which then sends back encrypted data. That data is then decrypted at the local client. And they made a browser plugin for it. How is this fundamentally different than public key encryption?
The performance is horrible. From the Mylar web site, "a 17% throughput loss and a 50 msec latency increase for sending a message in a chat application." A 17% throughput loss and 50ms latency is *huge* for something as trivial as a chat application. Imagine what happens when real data is being crunched.
There are still enough attack vectors that make this a non-starter. First off, the encryption itself is still brute-forceable by a determined attacker with enough resources. Second, it assumes a secure client environment. Finally, it assumes that your adversary plays by the rules and won't inject malicious code or backdoors into the software or encryption, with or without a complicit service provider. The client code can check authenticity? Cute, but only works if your adversary doesn't "require" that the service provider comply with a secret order to say that the code is authentic, even when backdoored.
Steve
The password is kept in LocalStorage (a feature of HTML5)
Which breaks for businesses that have standardized on IE 8 because it's all their intranet apps support.
you're a bit small minded if you can't think of applications that need interactivity beyond basic HTML components.
JavaScript haters would prefer that such rich applications be made with Qt, not HTML+JavaScript.
Never until it does. When will we learn?
so far.
Circle the wagons and fire inward. Entropy increases without bounds.
So, they think that it's a good idea to go back to the days where every application had to be downloaded and given free reign to access every document on your computer?
Of course they don't. That's what Sandboxie, FreeBSD jails, a dedicated user account for each application publisher (Android's approach), and other container technologies are for.
"If something needs to a key to be unlocked, it can be unlocked by anyone." by Neruos; 1997
Those are two separate issues. The "free reign" has already been answered by someone else, so I'll answer the part about downloading.
Yes, we need to go back to downloaded apps. The reason is trust, validation and security in what is now a dangerous online world.
Client-side Javascript that is downloaded per page cannot be validated even if it's readable, because there is no guarantee that each visit to the site will download the same code. It's even possible for the whole world to see clean JS code and declare it "trustworthy" while a selected target is handed compromised code. This makes a mockery of any attempt at checking or validation and trust assignment based on such checks.
But it gets worse. Most sites implement perimeter security, in other words using a firewall to block or control entry to classes of networked functionality based on protocol and source. Downloaded browser Javascript bypasses this perimeter security entirely and executes deep inside the privacy domain, so it takes us back to the bad old days before people learned that downloading untrusted executables and running them was extremely dangerous and only done by the clueless. Now the advocates of client-side JS expect everyone to be that clueless.
Inevitably the browser's software sandbox gets brought up in answer to that, but it's wishful thinking. All large software systems contain bugs, it cannot be avoided in the current state of the art, and the browser is one of the largest single applications in existence. Even leaving this inherent principle aside, the fact that there have been thousands of JS, DOM and browser holes, leakages, bugs and exploits over the last decade should be enough to banish that wishful thinking.
The answer to your question is clear. Downloaded per-page executable code needs to disappear, and fast. Today that means Javascript, but in principle it applies to any language that is used in this way. Not doing so plays directly into the hands of organized crime and other parties who benefit from the loss of trust, privacy, and security.
L33T Haxors announced that they have cracked the Mylar Secure Web App framework created by MIT researchers.
I mean, I don't want to rain on the parade of these people and I'm sure this is "better" in the security sense, than what most web apps do. However it's a fool's errand to suggest that any system will never have a security problem.
I've done an analysis based on what's in their paper and posted it to Schneier's blog. Link below.
https://www.schneier.com/blog/...
Spoiler: it's not trustworthy but it's good work in progress.
Nick P
Security Engineer
(High assurance security focus)
To clarify all misconceptions in other posts, having been to a talk of hers a few days ago, here's the encryption types involved:
* RND (salted symmetric key encryption) - used for columns where no sql manipulation is needed
* DET (unsalted symmetric key encryption) - used for columns that need to be looked up by equality
* Partially homomorphic encryption - used for aggregation such as SUM()
* Order preserving encryption - useful for inequality where clauses, indexes, aggregations such as MIN()
* Searchable encryption - allows something like ILIKE on text columns
OPE is the most dangerous, but is rarely needed for the most sensitive fields. They've run CryptDB on top of phpBB and
some other thngs with acceptable overhead. Let me know if you have other questions.
So far in all the post and articles focusing on encryption I've read, not a one has seem to ever consider using polymorphic data (brightnet technology) storage and retrieval as a means for encryption. Since polymorphic data is inherently encrypted by means of using a pool of multiuse or "ownerless" data blocks, the data in itself has no intrinsic meaning nor authored form. It simply is stored as arbitrary "white noise" blocks of seeming useless data. But the point of polymorphic (many-to-one) data is that individually these blocks means nothing, yet as if a sort of digital lego, when certain blocks are pulled together could virtually create just about any "readable" segment of data or whole data files.
All you would need is the hash key to know which blocks go together. This means that whole applications and its data could be virtually encrypted by way of these data blocks and retrieved. Put it simply, its like having a peer to peer type data query from a database instead of multiple networked systems. The key to this of course is the hash key that is the marker for how the data is returned and which blocks should be used.
Most people don't realize that the exact same blocks of data can exist in multiple files and types. The reason is purely mathematical. Here is an excerpt from a good buddy of mine that wrote a paper on the subject.
"This is the idea at the core of the polymorphic data system. It then takes it farther to show that each of these numbers can be used to access many different things simultaneously. Let’s name these numbers now, and add a couple more.
11230243302314110327264211 = A
12102741001515622171134513 = B
47379872610938161983471179 = C
02810398720484003497102380 = D
We showed above that (A+B) could represent, “Lawyers, Guns and Money”. Interestingly, at the same time (A+C) could represent, “Oops, I did it again!” Who then owns (A), Warren or Britney? Also (B+D) could represent, “Piano Man”. So who owns (B), Warren or Billy? Both (A & B) participate equally in multiple representations simultaneously. Likewise, since the data can represent nearly anything (and does) it is safe to assume that it is both a dessert topping and ceiling wax."