Forgot your password?
typodupeerror
Encryption Privacy Security The Internet

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

Posted by Soulskill
from the what-about-when-leak-exists-between-keyboard-and-chair dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Anonymous Coward

    I feel like this is what they all said.

  • by CBravo (35450) on Wednesday March 26, 2014 @02:33AM (#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.
    • by Anonymous Coward

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

      • by Anonymous Coward

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

      • by tepples (727027)
        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.
        • 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.

          • by tepples (727027)
            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.
            • 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.

        • by tattood (855883)

          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

          • by tepples (727027)

            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.

    • by gl4ss (559668)

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

    • by L-One-L-One (173461) on Wednesday March 26, 2014 @02:59AM (#46581835)

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

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

      • 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?!
        • 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 mech

          • 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

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

      • If it is searchable, then you can create a tracker.
      • by CBravo (35450)
        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.
    • by Anonymous Coward

      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 c

    • by eth1 (94901)

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

  • by xombo (628858) on Wednesday March 26, 2014 @02:42AM (#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.

    • by ModernGeek (601932) on Wednesday March 26, 2014 @02:47AM (#46581789) Homepage
      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!
    • Honestly, I would be happy if every website I deal with encrypted their passwords. We still haven't passed that low bar yet.
    • by thegarbz (1787294) on Wednesday March 26, 2014 @03:34AM (#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.

      • by swb (14022)

        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.

      • by Barbarian (9467)

        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.

    • by Anonymous Coward

      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!

      • by mwvdlee (775178)

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

      • by Archtech (159117)

        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 yo

    • by GuB-42 (2483988)

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

    • by Gothmolly (148874)

      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?

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

  • Stick to HTML & CSS.

    • by hh10k (725277)

      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?

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

        • by hh10k (725277)

          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?

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

  • /dev/null ?

  • by Anonymous Coward

    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

    • by tepples (727027)
      In theory, securing a web application against cross-site scripting is easy: use textContent instead of innerHTML.
  • by renzhi (2216300) on Wednesday March 26, 2014 @04:12AM (#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.

  • 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

  • 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
  • ***** Hard to see how to avoid the hushmail scenario ***** http://www.wired.com/threatlev... [wired.com] ***** http://www.wired.com/threatlev... [wired.com] ***** https://www.hushmail.com/about... [hushmail.com] ("But I thought the data was always encrypted") *****

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

    --Russian hacker

  • 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 un
    • 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.
    • by Lennie (16154)

      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.

  • 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 t
    • 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.

      • by swsuehr (612400)

        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

        • 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 until it does. When will we learn?

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

Make sure your code does nothing gracefully.

Working...