Internet Security: Is sending encoded data over SSL secure enough?
January 28, 2016 3:13 PM   Subscribe

We're sending the names and/or email addresses of users from their browsers on their computers to our databases. Are plan is to fragment and encode (not encrypt or hash) that data before transit over SSL and store it in our databases the same way. Is acceptable to the expectations of security professionals?
posted by jander03 to Computers & Internet (9 answers total)
 
When you create the RSA key be sure to choose a 2k length (2048) and you should be good to go.

Now remember that's on the wire, says nothing about the clients browser (compromised javascript) or your firewall but in transit unless its the best there is right now.
posted by sammyo at 3:23 PM on January 28, 2016 [2 favorites]


By encode, do you mean obfuscate or are you talking about encoding it in some sort of machine-readable way (like, say, putting into JSON format or something)? If you're trying to obfuscate the data in the browser, it'd probably be better to just encrypt it for real once the server receives it. There was (I thought) a good reason why you usually don't want to do the encryption in the browser but I can't remember why that is (or find the article saying such). In any case, though, a properly set up SSL-capable web server is good enough. (Yes, that means 2k lengths or better, and it means making sure you're not using ciphers that are old and crusty (no RC4), SHA2 hashing, TLS v1.2, etc. Here's some best practices for you and they also run an SSL server checker.). Properly set up SSL is really hard to screw with unless the connection or the browser itself has been tampered on the other end. And, as noted, if the browser has been tampered with, you're not necessarily going to know anyway.
posted by mrg at 3:32 PM on January 28, 2016 [2 favorites]


There are services like SSL labs that will grade your SSL setup. I'm not a professional at web security, so I can't speak to how good a grade you want to shoot for, but it will flag up anything really horribly wrong with your SSL.
posted by BungaDunga at 3:33 PM on January 28, 2016 [1 favorite]


There are so many avenues for compromise that just making sure your page is set up so that everything goes through a well-configured, up-to-date TLS (SSL is the old name) connection is pretty darn good. There's something like a 10% chance that the user's browser is compromised, so TLS, in-browser encryption, etc. wouldn't do any good anyway. Then the database on your end becomes the weak link. Put the same effort into securing that as data in transit.
posted by wnissen at 4:11 PM on January 28, 2016 [1 favorite]


Properly set up SSL is really hard to screw with...
+1

a) use a proven user authentication mechanism
b) use TLS
c) any encrypting/obfuscating from the client side is a waste of time
d) mitigate CSRF vulnerabilities
e) protect yourself from your own screw ups: encrypt the data at rest on the server side
posted by j_curiouser at 4:17 PM on January 28, 2016 [1 favorite]


Is acceptable to the expectations of security professionals?

Not really. If the connection is encrypted, the attacker can't read the data. But let's break down the threats:

An attacker can't man in the middle connection or read it. So that's good.

If the attacker has compromised the browser, you're screwed. They could be easily adding their own plugins to the browser that will send the data wherever they want.

If the attacker has compromised the server, you're screwed. They could easily make the server send whatever dummy protection instead of your fragmentation.

Just pick a good hash algorithm and hash the passwords on the server. If you need to encrypt it, make sure you encrypt the data at rest using a good algorithm. Using the browser to obfuscate, using some custom algorithm doesn't provide you with any protection using SSL won't give you. It's just a false sense of security.

So yes, sending data over SSL is enough, as long as you encrypt the data on the server afterwards.
posted by zabuni at 4:28 PM on January 28, 2016 [1 favorite]


This comes down to what threat you are trying to avoid/mitigate. SSL/TLS provides for a few things:
1. Encrypts traffic so that people observing the network can't see what is being sent
2. Identifies the identity of the server (that's the name of the server's SSL certificate)
3. Optionally identifies the identity of the client in the case where client certificate authentication is being used.

You have to ask yourself what encoding/obfuscating data in addition to SSL buys you. What do you hope to gain from encoding the data? I'll disagree with the above to say that clients can't be Man-In-The-Middle attacked since compromised PCs and ignorant end users are always susceptible to attacks but that is a hard thing defend against. The amount of effort you should put into worrying about that is proportional to the sensitivity of the data and likelihood of the occurrence.

As for your plans to store these obfuscated data chunks in your back end system you need to stop and consider if you intend to do this as a way to mitigate your back end data store from being stolen. While there is validity in thinking about how to mitigate the damage a breach would entail you are better off spending time and money and effort on making sure the breaches don't happen. Also, encoding/obsfucating data is likely to be woefully insufficient a deterrent once someone has your data.
posted by mmascolino at 7:28 AM on January 29, 2016 [1 favorite]


What is your threat model that makes you concerned about user names and e-mails going back and forth over the internet? Properly implemented TLS is pretty secure up to the nationstate level threat - if you're facing something like that, you should have professional security people working for your company. But you probably aren't. If they're using a corporate computer, they might be man in the middled by their corporate proxy, but in that case, the proxy is going to see all of the traffic and there isn't an expectation of privacy (in the US, overseas may vary).

Users names and e-mail addresses aren't terribly secret information and if it's something that having their affiliation with your site revealed would be embarrassing to them or whatever, you should be encouraging them to use aliases and throwaway e-mails.

Other than that, KISS. Use good TLS, encrypt names and e-mails before putting them in the database if you think it's necessary.
posted by Candleman at 2:49 PM on January 29, 2016 [1 favorite]


1st question always - What's the data we are protecting?

> names and/or email addresses of users

Barely even PII. Could be another data type depending on the website - users of a specific drug or sufferers of a certain disease would bring up HIPAA concerns. Are minors going to be users? Both issues would increase the amount of protection required, yet be mostly met by following the often-repeated phrase "Encrypt data at motion and at rest."

> Is acceptable to the expectations of security professionals?


There are standards for a reason - and that reason is they work. Use SSL as suggested above and enable encryption on the database. You don't have to, but you should.
posted by anti social order at 3:00 PM on January 29, 2016 [1 favorite]


« Older Need to find an on-line inexpensive expense...   |   What's in a name? ...Quite a lot, actually. Newer »
This thread is closed to new comments.