views:

69

answers:

3

I'm looking for a product that can provide browser-level encryption of textual data before it's sent to a backend server. HTTPS can be the secure transport mechanism but we need the packet to be encrypted on the browser first. The data packet must end up in encrypted form on the backend database. Use case is: user fills out form on the browser, user submits the form data, before sending the data over the wire, the browser encrypts the data, the data ends up in the backend database in encrypted form, at some point in time, all of the data will be collected from the backend database, moved to a disconnected computer and decrypted at that point.

+2  A: 

That's what HTTPS (SSL/TLS) is for. It should be plenty secure enough.

But as you state in your answer to my query, you want the form data to be stored in the database in its encrypted form. A quick Google search brings up JQuery.Gibberish-AES. It's a JQuery plugin that will do AES encryption and can utilise an RSA public key.

Using this you could generate a public/private key pair, keep the private key on the super-secret disconnected computer, and publish the public key with your form. You can then encrypt the data, store it in your database, and even if someone got root access to the database server they could decrypt the data because the secret key is on your secure disconnected machine.

I'm sure there'd be similar plug-ins/libraries for other client-side frameworks if you don't use JQuery.

I'd still use SSL/TLS for the connection, because that provides the server authentication (and client authentication if you want) to protect against a man-in-the-middle.

Andrew Cooper
Thanks Andrew. This is very helpful.
Jeff Rubingh
+3  A: 

HTTP over SSL/TLS (HTTPS) is secure enough. It actually is as secure as it gets.

With SSL/TLS you can choose the cipher suite and adjust the encryption algorithms and key sizes according to your needs. 2048-bit RSA and 256-bit AES should be secure enough.

In addition to encryption, SSL provides authentication. AND it is natively supported by virtually every browser in existence. Please don't reinvent the wheel.

NullUserException
Thanks. My mistake in phrasing the question. We want the packet to be secured prior to transport and then to live in the database in encrypted form. HTTPS is fine but we want to encrypt the packet before transporting it.
Jeff Rubingh
@Jeff Is the intent of this to make the data private to the server receiving it? In other words, do your clients not want you to be able to see their data?
NullUserException
@NullUserExceptoin That's right. The data will arrive encrypted and be stored in the database in encrypted form. At some point in the future it will be transferred manually to a disconnected machine and decrypted there.
Jeff Rubingh
@Jeff I see. Is this just text we are talking about? How large would each submission be?
NullUserException
@NullUserException Yes, just text. Very trivial, likely < 1KB
Jeff Rubingh
+2  A: 

I agree that TLS is good enough for a lot of cases and I've written a little about it in my journey to see how it works. It does have some issues like governments being able to compel certificate authorities to grant certificates to allow man-in-the-middle attacks, but in general it's pretty good.

You might be interested in the design of systems like LastPass that encrypt things in addition to using TLS (details here). I would say that your best approach if you think TLS isn't good enough is to do something in addition to it rather than in lieu of it.

Jeff Moser