1

Say I have a PHP application and want the users data to be encrypted before it it gets to the server (to prove to users that their data will not be data mined or resold for advertising).

Similar question was asked here ( Secure Javascript encryption library? ) and implies that this is not going to work, but with the increase in privacy interest amonsgt users this requirement is only going to get greater over time.

Example, using the Stanford library (http://crypto.stanford.edu/sjcl/) a web form has an additional ‘long’ password field which the user pastes in (probably from email for example)

  sjcl.encrypt(txtPassword, txtFormFieldToBeEncrypted)

The encrypted data is sent to the PHP page, and the process is reversed when the page is loaded.

Would this work if the users used Chrome or another browser that remembers form values - obviously this is not a secure result, but would this be effective enough to keep the users information private from the host server?

EDIT: Just to be clear, I am only interested in making the information invisible to the host server, and understand that this solution wont protect from 3rd party attacks

Community
  • 1
  • 1
acutesoftware
  • 1,091
  • 3
  • 14
  • 33
  • 2
    _want the users data to be encrypted before it it gets to the server (to prove to users that their data will not be data mined or resold for advertising)_ Brilliant! – Aleks G Jun 25 '13 at 12:49
  • 11
    Don't encrypt it yourself, use SSL – Mark Baker Jun 25 '13 at 12:49
  • yes SSL saves you from eavesdropping. – Arun Killu Jun 25 '13 at 12:54
  • Who would mine that data? You or some unknown party that is somehow eavesdropping the communication? – N.B. Jun 25 '13 at 12:57
  • What is the reason you're looking into JS encryption over SSL? Are you trying to avoid the SSL subscription fees? – MrCode Jun 25 '13 at 13:08
  • No, the point is simply to have a web application that users can be comfortable using KNOWING that any information they provide will not be used for advertising / datamining etc. – acutesoftware Jun 25 '13 at 13:09
  • Then the best choice is SSL because the use of SSL will show the "secured" icon/messages in the browser. Using JS encryption won't, infact using JS encryption will most likely degrade user confidence in your security because they may wonder why the browser is showing "unsecured". – MrCode Jun 25 '13 at 13:12
  • @acutesoftware - you do realize what you're saying makes no sense, right? There are two potential parties who can use user's data - an eavesdropper who you get rid of by using SSL and **YOU**. How will the encryption ensure the user that YOU won't use that data? Or, do you intend to have their data in encrypted format on your servers, in which case it's really useless to you as well? – N.B. Jun 25 '13 at 13:18
  • 3
    @N.B. Yes, that is exactly what I want - my application will only ever see encrypted data which *I* cannot see. I know of a lot of (older) business users who would really like this feature, iff it could be implemented. – acutesoftware Jun 25 '13 at 13:21
  • 1
    It can be implemented, but new questions arise. What you asked was just to encrypt the data between client and server. That's what SSL is used for. As for how you hide the information ON the actual server.. that's a whole another pair of sleeves. How do you encrypt, does each new user have their own decryption key, what type of encryption (symmetric, asymmetric), do you use an encrypted drive for your db's data dir etc. – N.B. Jun 25 '13 at 13:26
  • 1
    @N.B. If all the server does is store encrypted blobs nobody but the user holds the key to, the server-side storage becomes almost irrelevant. Of course you'll want to store it as securely as possible, but even if the data got loose, it'd still be encrypted; hopefully using a strong algorithm. – deceze Jun 25 '13 at 13:30
  • 1
    @deceze - I'm saying that designing this system isn't as simple as it sounds. First off, there's the concept of key. User has to store a key of some sorts, be it username/password. Then the data has to be decrypted somewhere, be that the server or user's browser etc.. Bottom line is that this question is much wider than it originally seems and can't be answered simply as that, because the problem isn't "what method to use", the problem is "how to design such a system". – N.B. Jun 25 '13 at 13:37
  • 1
    @N.B. It seems to me the question is really just: *"is it feasible to encrypt data client side using a key (password) only the user holds and just sending and storing encrypted blobs to the server?"* To which the answer is: yes. The server needs to do very little, it's just a storage device which never gets in contact with the real sensitive data. Every security sensitive operation is done client side. Yes, this system still need proper designing, but it's certainly possible. I cited a very widely used, well working example below. – deceze Jun 25 '13 at 13:42
  • @deceze - I really do understand what the *goal* of the question is, I'm just saying that, although very possible to do so, still poses a plethora of other questions. There is no out of the box solution here, it must be designed and coded. – N.B. Jun 25 '13 at 13:48
  • @N.B. Then isn't that *the* answer? :) *"Yes, but the predictable weak points are A, B and C; design around those properly."* – deceze Jun 25 '13 at 13:50
  • @deceze - you're missing the point here, I'm not trying to answer the question, I'm trying to steer the OP towards the actual question he needs to ask :) and now we're having a debate while we're both talking about the same thing, which is kind of frustrating :) – N.B. Jun 25 '13 at 13:58
  • @acutesoftware Is the application just an interface for something else? Couldn't the users just use gpg on their computers then post the data? – jett Jun 25 '13 at 15:34
  • @jett yes that would work - the idea is to encrypt the data so the host cannot see it. It would be nice to have a JS (or other) standard library which did that for the user. – acutesoftware Jun 25 '13 at 22:44

4 Answers4

1

Protection on the page is useless, for the simple fact that the encryption key / mechanism will also be in the scope of the page and can thus be tampered with by a malicious party (or by the user itself when inspecting the page).

To avoid data going over the line unencrypted there is also no reason to "roll your own"(tm), because for that there is SSL.

If you want to make sure that the data that you receive on the server was actually originating from a page that you control, you can rely on CSRF protection.

Jan Jongboom
  • 26,598
  • 9
  • 83
  • 120
  • Almost same answer in almost the same moment :) – Piotr Stapp Jun 25 '13 at 12:56
  • "the encryption key / mechanism will also be in the scope of the page" - the key isn't stored in the page, OP intends to email it to the user. Besides, if an attacker can read and modify a victim's DOM, then enctyption for the data transfer is the least of your worries. I agree that SSL is the correct way to do what he wants. – MrCode Jun 25 '13 at 13:03
  • 1
    I realise that it is not a secure solution overall, but the point is to try and make the information secure from the host (3rd party attacks is another story) – acutesoftware Jun 25 '13 at 13:11
1

First of all use SSL it is for an only way for secure communication. If you make encryption in JavaScript it is trivial to decrypt your message (because all your code with keys is public).

If you worry about CFRS attack use anti-forgery token (more here: http://bkcore.com/blog/code/nocsrf-php-class.html)

Piotr Stapp
  • 19,392
  • 11
  • 68
  • 116
  • 1
    Yes SSL is the best way to do this but "because all your code with keys is public" - The key isn't public. It is personal to the user and is sent to his email. It is not stored within the page itself. – MrCode Jun 25 '13 at 13:06
1

Here are a bunch of reasons why javascript encryption in the browser is almost always a bad idea.

You need to think deeply about your trust model. Do the users trust the server? If not, there is no hope for trustworthy javascript crypto since the crypto software itself comes from the server. If the users do trust the server, why does the data need to be encrypted client-side? Just use SSL to secure the connection, then have the server encrypt the data before storing it.

Adam Bliss
  • 645
  • 4
  • 9
  • That is the point - I don't want the users to NOT have to trust the host application. Sounds strange, but surely there is a way to do this. You could achieve it by giving them a portable encrypter so instead of typing in "Meeting at 9am" it encrypts it and posts HKGKTKFKDKFK – acutesoftware Jun 25 '13 at 13:17
  • @acutesoftware He has a point though. You provide the encryption software, so the users would still have to trust you either way. You may be encrypting the data, but maybe you're sending the key along with the data too. Just because you're "doing encryption" does not automatically make you trustworthy. – deceze Jun 25 '13 at 13:20
  • 1
    @acutesoftware Having said that, this model is working out fine for the folks at Lastpass, among others. – deceze Jun 25 '13 at 13:20
  • I agree that because the code comes from the server it is an issue, but if the encryption library came from a standard place (stanford, or google) then it would be easy to make sure that the site was always pointing to that (maybe not for end users, but pretty damn clear to anyone who pressed Control U). Also Lastpass seems to give you a download, which would solve my problem (encrypting at the client first), but I was hoping there would be a way without an executable being needed. – acutesoftware Jun 25 '13 at 13:30
  • 1
    @acutesoftware Lastpass offers plugins for virtually everything as a convenience, but they have a pure Javascript implementation too. – deceze Jun 25 '13 at 13:32
1

It's perfectly possible to do this, Lastpass for instance built their business model on it. All their server does is store an encrypted blob which they cannot do anything with, all encryption and decryption happens on the client; including a Javascript implementation in the browser. The entire blob of encrypted data is downloaded into the client, where the user's password decrypts it; and in reverse on the way back up to the server.

So if your question is whether it's possible: absolutely. It's also a lot of work, since you will need to be providing the same en-/decryption code for as many platforms as you want to support. You'll also need to secure every context where that code will run, to prevent third parties from injecting code which would allow them to access the client side decrypted data. So, everything needs to go over SSL with no 3rd party content being allowed to be injected.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • Thanks for your answer, though LastPass needs to install a browser extension (executable), but it could be a solution. – acutesoftware Jun 25 '13 at 13:32
  • 1
    @acutesoftware It doesn't *need* it, but it's more convenient. For a good high-to-low level discussion about Lastpass, listen to http://twit.tv/sn256. – deceze Jun 25 '13 at 13:34
  • I have had a look at LastPass but cant seem to find how to use it without downloading the extensions - it is part of the premium content only? – acutesoftware Jun 25 '13 at 14:10
  • @acutesoftware Just "Sign In" to access your entire vault from the browser. – deceze Jun 25 '13 at 14:12