Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MIT Researchers Create Platform To Build Secure Web Apps That Never Leak Data

Soulskill posted about 6 months ago | from the what-about-when-leak-exists-between-keyboard-and-chair dept.

Encryption 90

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."

cancel ×

90 comments

Sorry! There are no comments related to the filter you selected.

Never say never (2)

Anonymous Coward | about 6 months ago | (#46581747)

I feel like this is what they all said.

How can you search data (2)

CBravo (35450) | about 6 months ago | (#46581767)

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.

Re: How can you search data (3, Insightful)

Anonymous Coward | about 6 months ago | (#46581783)

Why do you need to search or sort credit card info?

Re: How can you search data (1)

Anonymous Coward | about 6 months ago | (#46583215)

Why do you assume the only data stored on a server is a credit card number?

Re: How can you search data (2)

tepples (727027) | about 6 months ago | (#46583261)

An online store needs to search or sort the identities of products purchased with the credit card, as well as the shipping addresses for orders purchased with the credit card, in order to fulfill the orders. A store offering a subscription arrangement needs to search for upcoming expiration dates so that it can 1. notify each subscriber that the card on file with the store is about to expire and 2. charge the ETF on the last valid day if the subscriber fails to update the card by the expiration date.

Re: How can you search data (1)

ilsaloving (1534307) | about 6 months ago | (#46584521)

If you're using the card info purely as a primary key, then it should work just as well in an encrypted form as it would in it's original.

Re: How can you search data (1)

tepples (727027) | about 6 months ago | (#46584837)

But you still need to store which cards are set to expire in a given month. And you still need to store some key with which to decrypt the card number when charging the customer for the subscription each month.

Re: How can you search data (1)

ilsaloving (1534307) | about 6 months ago | (#46592413)

True, if that was part of the use case. Recurring payments weren't mentioned by the parent.

But yeah, if you *need* access to the data (any data) then it can't be encrypted only on the user side. At that point there's nothing you can do besides being dilligent in your security.

Re: How can you search data (1)

tattood (855883) | about 6 months ago | (#46587997)

A store offering a subscription arrangement needs to search for upcoming expiration dates so that it can 1. notify each subscriber that the card on file with the store is about to expire and 2. charge the ETF on the last valid day if the subscriber fails to update the card by the expiration date.

Why do the expiration dates need to be encrypted? A thief can't do anything with just the expiration date without also knowing the CC number

Re: How can you search data (1)

tepples (727027) | about 6 months ago | (#46589475)

Why do you need to search or sort credit card info?

search for upcoming expiration dates so that it can notify [customers]

Why do the expiration dates need to be encrypted?

They may not. But like credit card numbers, expiration dates are "credit card info", and notifying subscribers of cards due to expire is still "search[ing] credit card info". Besides, a store still needs to store the credit card numbers with which to charge the customer for each month, and the periodic billing process needs to store the key with which to decrypt the credit card numbers. So does the refund process for any store that sells physical goods and accepts returns.

Re:How can you search data (2)

gl4ss (559668) | about 6 months ago | (#46581791)

well.. you have all the clients connected all the time and when a search is done the server sends the search to all the clients and they decide if they want to answer that search query... ..... . .. .. ...

sounds real nice in a lab with 5 clients, right? but really shitty if you start to think about it at all.

(sure, plenty of web apps work nicely for that too because you don't do searches and only interact with a limited number of other clients..)

Re:How can you search data (5, Informative)

L-One-L-One (173461) | about 6 months ago | (#46581835)

It's called "searchable" encryption. It already exists in a few commercial products.

See for example:
http://www.ciphercloud.com/tec... [ciphercloud.com]

Re:How can you search data (1)

L4t3r4lu5 (1216702) | about 6 months ago | (#46582695)

Why is this even a thing? All reversible encryption (which in itself is a tautology) is searchable.

Plaintext record ID > Encryption+key+salt etc > Cyphertext record ID. Search for the cyphertext record ID. Bring encrypted record back from database. Encrypted record > Encryption > Plaintext record.

How is this a marketable product?!

Re:How can you search data (2)

L-One-L-One (173461) | about 6 months ago | (#46582815)

Why is this even a thing? All reversible encryption (which in itself is a tautology) is searchable.

Plaintext record ID > Encryption+key+salt etc > Cyphertext record ID. Search for the cyphertext record ID. Bring encrypted record back from database. Encrypted record > Encryption > Plaintext record.

How is this a marketable product?!

Searchable encryption is more complicated than you think. For example if I encrypt the sentence "I like reading slashot" with traditional encryption I will get a block binary data that is meaningless. Now suppose I want to check if that block contains the word "slashdot"? Your "cyphertext record id" approach won't be of much help. You need a few tricks to do it correctly, notably adding some metadata and additional cryptographic mechanisms. To make things more complicated, you often need the encryption mechanism to be "format preserving": if you encrypt a string field you get a string field, if you encrypt a number field you get a number field, while traditional cryptography outputs binary data.

Note that you may have misunderstand how encryption works, if you believe that all reversible encryption is searchable. Good encryption is randomised: if you encrypt the same plaintext twice with the same key you get 2 different cypher-texts (to take your analogy, you must use different salts).

Re:How can you search data (2)

Ronin Developer (67677) | about 6 months ago | (#46584481)

With symmetric encryption, when you encrypt with the same encryption key, you WILL get the same output that can be decrypted using the same key.

With password based encryption, you start with a passphrase and a salt, The passphrase and salt are combined and then run through a secure hash an agreed number of times. The resulting hash is the encryption key that is used with the cipher to perform the actual encryption. The salt and iteration count are why you can reuse the same passphrase.

In this context, if you alter the salt or number of iterations, you will get a different encryption key for the same passphrase and the resulting cipher text will be different. Of course, you should never encrypt using a straight block cipher but rather should use something like cipher block chaining (CBC) which uses the results of the previous encryption to seed the encryption of the next block to encrypt. This action helps to make cryptanalysis harder on the resulting encrypted code.

In simpler terms:
CipherText = Encrypt(passphrase, salt, interations, ciphermode, Plaintext).
PlainText = Decrypt(passphrase, salt, interations, ciphermode, CipherText)

Re:How can you search data (1)

L4t3r4lu5 (1216702) | about 6 months ago | (#46591345)

Exactly what I was getting at. I was including op mode, iterations etc in "encryption" for brevity. Very few here (including me) understand what it actually does, just that it's part of good "encryption". The fact that it is reversible by definition is all I was getting at. If you couldn't recover the plaintext, it would be more like a hashing algorithm.

Re:How can you search data (1)

EndlessNameless (673105) | about 6 months ago | (#46606175)

I think you don't understand what searchable encryption is. It means you can search the data without decrypting it. Once you find the records you need, you decrypt them.

The only data that is ever decrypted is the actual data that you want.

If you're like me, you probably had a brief moment of "OMG, how is that even possible?" when you first grasped it. And that is why it is an expensive software package for those who need it.

Re:How can you search data (1)

Doomsought (3407379) | about 6 months ago | (#46585191)

If it is searchable, then you can create a tracker.

Re:How can you search data (1)

CBravo (35450) | about 6 months ago | (#46585913)

I understand the equality operator is transferrable to the encrypted domain. There are other sql operators that are not (without leaking information).

I can only see a future for private clouds.

Re:How can you search data (0)

Anonymous Coward | about 6 months ago | (#46582249)

There are encryption methods out there that allow you to query for something that might be in the data and it will give you a true or false accordingly. I remember the first time I seen such an algorithm, it blew my mind.

Re:How can you search data (1)

Anonymous Coward | about 6 months ago | (#46583239)

A friend of mine did some work on this in grad school.

For a simple scheme, say you have a 32 bit integer as data but you store it in a 64 bit SQL field. You can come up with transformations that conserve ordering (e.g. 1 -> 15, 2 ->29, 3-> 54 and so on). You keep the key to that transformation in a local SQL proxy server and code and decode the data before sending it to the backend (in the cloud, for example). Nowadays this could be implemented in the model of your MVC application. The SQL server can still do ordering and range queries (parameters also get coded by the proxy), but the data isn't stored in the clear.

Now, if you coded, say, a person's wage, an attacker that gains access to your cloud storage could tell that the CEO earns more than everyone else, but not how much he actually earns (except statistically given the general properties of the transform).

That's a simple scheme, and the hard part of the work was figuring out how much information was leaking. There are also obvious attacks (hack the server then send queries through the UI for example), but I think they got much farther with it after I saw the work.

Re:How can you search data (1)

eth1 (94901) | about 6 months ago | (#46583375)

Well, if you're encrypting, it means the keeper of the data isn't supposed to know what it is, which means they can't do any data mining, selling, etc. of it anyway, which would be where the ability to do queries on the data would be useful. If you're encrypting everything, then all you need is to be able to find the records, and you could use hashed account names or something to index those.

So yes, it would be difficult to search/sort on the encrypted data, but then that's sort of the whole point...

I've implemented something similar (4, Interesting)

xombo (628858) | about 6 months ago | (#46581779)

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.

Re: I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46581781)

I agree in that this isn't just a business

Re: I've implemented something similar (4, Insightful)

ModernGeek (601932) | about 6 months ago | (#46581789)

I agree in that this won't be implemented because of the business implications but would also go on to say that this solution is unoriginal and undeserving of all the pomp and circumstance that the media and the educational institutions are giving it, before we know it they're going to give out Ph.D's and there patents for a high school paper on using electrolysis to make hydrogen and oxygen. Call the press!

Re: I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46581823)

Wow you guys really know your stuff. Wish I had mod points to mod this up.

Re: I've implemented something similar (1)

ModernGeek (601932) | about 6 months ago | (#46581827)

* three patents

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46581843)

Their solution is better... because the power-that-be can still have their way in the weakness of the key for encryption.

It won't leak to casual data-pirate, but the governments won't be at pain either. Guess who is to valid the application in the store ? and who will get the pressure, now a single point, to weaken the key generation... with of course a secret injunction to not tell.

I need a canary.

Re:I've implemented something similar (2)

phantomfive (622387) | about 6 months ago | (#46581853)

Honestly, I would be happy if every website I deal with encrypted their passwords. We still haven't passed that low bar yet.

Re:I've implemented something similar (3, Interesting)

thegarbz (1787294) | about 6 months ago | (#46581943)

There's another side to this too. You won't see this scheme implemented because encrypted data can not be de-duplicated, and can not be compressed. Effectively your solution increases the cost of doing business, both in terms of bandwidth and in infrastructure.

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46582433)

The cleartext could be compressed in the browser before encrypting. It could also be hashed in the browser and the hash used for deduplication, but I don't like the idea because it means known files (e.g. movie rips or leaked datasets) can be associated with users. So maybe deduplication isn't possible in a safe way, but compression is.

Re:I've implemented something similar (1)

swb (14022) | about 6 months ago | (#46582735)

How much of "the data" needs to be encrypted and how much can be stored unencrypted?

In a lot of applications there seems to a subset of data that is sensitive and needs to be encrypted while much of it seems like it could be left unencrypted. There may be situations where all of it needs to be encrypted, but I'm guessing that means its stored encrypted now which means its not available for dedupe or compression anyway.

Re:I've implemented something similar (1)

Barbarian (9467) | about 6 months ago | (#46582831)

There's another side to this too. You won't see this scheme implemented because encrypted data can not be de-duplicated, and can not be compressed. Effectively your solution increases the cost of doing business, both in terms of bandwidth and in infrastructure.

Encrypted data can be compressed...just you have to compress before encrypting.

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46588643)

The bandwidth and infrastructure costs are inconsequential. Methinks you doth protest too much.

Anyone not implementing applications this way, where security of data is important, is either uninformed or lazy.

Re:I've implemented something similar (1)

Anonymous Coward | about 6 months ago | (#46581945)

So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible! This sounds like a terrible solution!

Re:I've implemented something similar (1)

mwvdlee (775178) | about 6 months ago | (#46582005)

This.
I'd have to be on the support side of an application implementing this.

Re:I've implemented something similar (1)

chrisfromnowhere (531442) | about 6 months ago | (#46582333)

So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible! This sounds like a terrible solution!

Easy. The client is prompted to re-authenticate with the users credentials. The server transfers the encrypted data and the users key (password protected) to the client. The user password is used along with their key to decrypt the data and store in local storage. You could (and should) even store the data in local storage encrypted, and require the user to re-authenticate to view sensitive information. This is how lastpass works. This is also (in a nutshell) how OwnCloud does server side encrypted storage. http://blog.schiessle.org/2013... [schiessle.org]

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46588675)

This is exactly how it works. If the key is no longer in LocalStorage, it prompts the user to input it again.

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46582501)

So you don't keep local backups of the data you store in the cloud? Yours sounds like a bad solution.

Re:I've implemented something similar (1)

Archtech (159117) | about 6 months ago | (#46584375)

So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible!

Actually, that objection applies to all encryption systems. You must have a key - which must also be hard to guess, thus fairly long and random - and that key must always be available to YOU. Once you recognize the necessity, there are many ways to handle it. Two or three USB sticks, for example (in case you lose one).

More generally, the objections to this approach seem to be largely based on cost and inconvenience. That's fine: you simply have to take a view of how much security and privacy are worth to you.

Re:I've implemented something similar (2)

GuB-42 (2483988) | about 6 months ago | (#46582653)

In many cases people prefer the ability to recover their data when they forget their password over the additional security of client-side encryption.

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46588751)

This concern was not relevant for the type of application I built. The security of the data and the ability to keep it private from the service provider was more important than human convenience in the event they lose the password. There are certain industries where this is necessary.

Re:I've implemented something similar (1)

Gothmolly (148874) | about 6 months ago | (#46582783)

So instead of keeping the password on the server, where you have some measure of control, you trust the client's unknown browser running on unknown hardware to keep it safe?

Re:I've implemented something similar (0)

Anonymous Coward | about 6 months ago | (#46588617)

Correct. This way only an individual's data can be compromised, not the entire server. Also this places their security in their own hands vs. taking it up as a liability of the service.

Re:I've implemented something similar (1)

DuckDodgers (541817) | about 6 months ago | (#46583163)

You won't see it implemented in free services for the reasons you describe. But it could work as a pay service. Most people will skip that in favor of free services that scrape their data, but some might.

I'm tempted to rent a server from Amazon or DigitalOcean or whoever and put the application on it myself, so I can access my data from anywhere without dealing with advertisements and privacy concerns.

No localStorage in IE 8 (1)

tepples (727027) | about 6 months ago | (#46583299)

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.

Re:No localStorage in IE 8 (1)

BitZtream (692029) | about 6 months ago | (#46583379)

Theres a plugin that solves that problem.

Re:No localStorage in IE 8 (0)

Anonymous Coward | about 6 months ago | (#46588715)

For those, it's just stored in a local variable and re-prompts any time it loses the variable (i.e. a full page reload). It's less convenient, but there are work-arounds.

Quit Using JavaScript! (1, Insightful)

littlewink (996298) | about 6 months ago | (#46581859)

Stick to HTML & CSS.

Re:Quit Using JavaScript! (-1)

Anonymous Coward | about 6 months ago | (#46581919)

HTML and CSS are obsolete. Now I use a canvas and JavaScript or WebGL scalable interactive displays.

Re:Quit Using JavaScript! (1)

hh10k (725277) | about 6 months ago | (#46582675)

You can do a lot with just HTML and CSS, but you're a bit small minded if you can't think of applications that need interactivity beyond basic HTML components.

And you obviously didn't RTFA, because their approach is about defending from security vulnerabilities on the server itself. Are we to stop using executable code on the server too?

JS haters want native apps instead (1)

tepples (727027) | about 6 months ago | (#46583307)

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.

Re:JS haters want native apps instead (1)

hh10k (725277) | about 6 months ago | (#46583751)

JavaScript haters would prefer that such rich applications be made with Qt, not HTML+JavaScript.

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?

Jailed native apps (1)

tepples (727027) | about 6 months ago | (#46583977)

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 [sandboxie.com] , FreeBSD jails, a dedicated user account for each application publisher (Android's approach), and other container technologies are for.

Explaining why browser JS needs to disappear (0)

Anonymous Coward | about 6 months ago | (#46585869)

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?

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.

Re:Explaining why browser JS needs to disappear (1)

Lennie (16154) | about 6 months ago | (#46588497)

If you read the article, you would find they download the signed application code and have a generic browser extension which verifies the signature of the code.

This is some what similar to what CryptoCat does, but the browser extension works only with CryptoCat.

But as their browser extension is generic then it can be made into a standard to be part of every browser, so their would be nothing to install.

/dev/null (0)

BlackPignouf (1017012) | about 6 months ago | (#46581895)

/dev/null ?

Oakland Traffic School (-1, Offtopic)

TrafficSchoolonline (3525699) | about 6 months ago | (#46581979)

If you get a traffic ticket in Oakland, our online traffic school can help you to get it off your record. Our online traffic school is licensed by the Department of Motor Vehicles of California (DMV) and approved by the Oakland Court. Complete our traffic school online in 3 simple steps: Step 1: Register with our online course with your basic information. Step 2: Complete few easy to read sections with brief quizzes. Step 3: Take the final exam. Our Online Traffic School is APPROVED by the following courts Oakland Court Visit our site: http://trafficschool2u.com/blo... [trafficschool2u.com]

Encryption alone isn't the holy grail. (1)

Anonymous Coward | about 6 months ago | (#46581991)

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.

Re:Encryption alone isn't the holy grail. (1)

tepples (727027) | about 6 months ago | (#46583315)

In theory, securing a web application against cross-site scripting is easy: use textContent instead of innerHTML.

Ridiculous (0)

Anonymous Coward | about 6 months ago | (#46581995)

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.

Re:Ridiculous (1)

SydShamino (547793) | about 6 months ago | (#46586047)

So because the NSA could install a keylogger on every gmail user's machine worldwide, google shouldn't bother to encrypt the data on their internal gmail servers where the NSA was previously snooping on all of it at once?

Of course there's always a weak point. Make that point less weak and the work to steal the data gets a little harder - maybe hard enough to defer the attacker - until the attacker adapts. Then fix the new weak point, and iterate until death.

California Counties and Courts (-1, Offtopic)

TrafficSchoolonline (3525699) | about 6 months ago | (#46582009)

Our driving safety course fully meets California State requirements and is licensed by the California Department of Motor vehicles(DMV). 100% licensed for all courts and counties in California. Our online traffic course helps you earn the Certificate of Completion you need, but also gives you a great online educational experience. We take all of the information and break it down so that it is easy to understand, easy to remember and fun to study. http://trafficschool2u.com/blo... [trafficschool2u.com]

Did this in 2005 (2)

renzhi (2216300) | about 6 months ago | (#46582031)

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.

What can possibly go wrong? (0)

Anonymous Coward | about 6 months ago | (#46582039)

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.

Re:What can possibly go wrong? (1)

Lennie (16154) | about 6 months ago | (#46588523)

Did you know Mozilla is building a new browser engine build in their new safe Rust language so fix that problem ones and for all ?

http://en.wikipedia.org/wiki/S... [wikipedia.org]
http://en.wikipedia.org/wiki/R... [wikipedia.org]

That method would at least eliminate all those pesky buffer overflow bugs in browsers.

What about complex sites though? (1)

Adam Jorgensen (1302989) | about 6 months ago | (#46582051)

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?

1991 called (1)

antifoidulus (807088) | about 6 months ago | (#46582059)

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.

Yuo 7Ail it (-1)

Anonymous Coward | about 6 months ago | (#46582229)

wall: *BSD faces a Fact: *BSD fIS A

"PRISM proof" my ass (0)

Anonymous Coward | about 6 months ago | (#46582475)

"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.

Re:"PRISM proof" my ass (1)

Lennie (16154) | about 6 months ago | (#46588561)

"How do I notice that the Javascript they serve me is secure, if I'm not to trust the server?"

They use a browser extension to very the signature of the downloaded Javascript code.

But their browser extension is generic, so it could be made into a standard so it will be part of the browser.

"The fact that Mozilla supports DRM now means that soon I can't even trust Firefox without any addons."

As far as I know Mozilla/Firefox does not support Encrypted Media Extensions and don't seem to have the intention to do so.

analog hole (1)

Gothmolly (148874) | about 6 months ago | (#46582793)

Eventually the data has to be rendered and presented for use by the application user. I'll just screen-scrape, thanks.

--Russian hacker

Seriously? RTFM (1)

shellster_dude (1261444) | about 6 months ago | (#46583033)

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).

Re:Seriously? RTFM (1)

DMUTPeregrine (612791) | about 6 months ago | (#46583905)

You don't even need XSS-like attacks. If you compromise the server you can re-write all the JS to send the encryption keys, the plaintext, or whatever you want to your server instead. Or back to the original server, and have it forward things on to you.

Re:Seriously? RTFM (1)

Lennie (16154) | about 6 months ago | (#46588583)

I wonder if you read the PDF, if you did you would know they use a browser extension to verify signed Javascript/HTML/CSS code.

So an attacked of the server can not modify the code unless they have the private key which is used for signing.

Interesting but still... (0)

Anonymous Coward | about 6 months ago | (#46583037)

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.

Re:Interesting but still... (1)

Lennie (16154) | about 6 months ago | (#46588635)

The attack they are trying to fix is a bad actor on the server.

If the software on the user's computer is compromised or the user is stupid enough to print it on paper and leave it at the desk unattended... then those kind of things are out of a web application programmer.

The real problem is eventually you have to present the clear text to the user, what the user does with the clear text isn't an easy problem to solve.

I'm glad if they at least solved the untrusted server problem.

April Fools Comes Early? (1)

swsuehr (612400) | about 6 months ago | (#46583115)

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

Re:April Fools Comes Early? (1)

cryptizard (2629853) | about 6 months ago | (#46584613)

First off, the encryption itself is still brute-forceable by a determined attacker with enough resources.

I realized you don't know what you're talking about right here. It would take until the heat death of the universe to brute force a 128-bit AES key.

Re:April Fools Comes Early? (1)

swsuehr (612400) | about 6 months ago | (#46584963)

I realized you don't know what you're talking about right here. It would take until the heat death of the universe to brute force a 128-bit AES key.

Seems like you're making an assumption that AES itself hasn't been backdoored and that the implementation of the same is also correct, neither of which I would assume. Steve

Re:April Fools Comes Early? (1)

cryptizard (2629853) | about 6 months ago | (#46585773)

Pretty sure you said brute-forcable which means just trying every key. As far as AES being weak, it is probably the most trusted cipher in existence. It has been around for over 15 years with the smartest cryptographers in the world trying to break it and no flaws have been found. Compare that to other ciphers like DES which researchers were skeptical of on day one and still took 20 years to break.

Never leaks until it does. (1)

oscrivellodds (1124383) | about 6 months ago | (#46583353)

Never until it does. When will we learn?

Secure Web Apps That Never Leak Data (1)

NikeHerc (694644) | about 6 months ago | (#46583825)

so far.

By Neruos (0)

Anonymous Coward | about 6 months ago | (#46585001)

"If something needs to a key to be unlocked, it can be unlocked by anyone." by Neruos; 1997

In breaking news... (0)

Anonymous Coward | about 6 months ago | (#46588775)

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.

my security analysis at Schneier blog (1)

Kishin (2859885) | about 6 months ago | (#46589825)

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/... [schneier.com]

Spoiler: it's not trustworthy but it's good work in progress.

Nick P
Security Engineer
(High assurance security focus)

Clarifications (1)

mstefanro (1965558) | about 6 months ago | (#46591437)

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.

Why don't they just use Polymorphic data? (0)

Anonymous Coward | about 6 months ago | (#46595321)

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."

Re:Why don't they just use Polymorphic data? (1)

mstefanro (1965558) | about 6 months ago | (#46596309)

Can you detail how can this support any of the features of a relational database? Filtering rows, joining tables, aggregation, ordering.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>