You are viewing limited content. For full access, please sign in.

Question

Question

HTTP Form Post Content Encoding

asked on March 5, 2019

I am trying to understand how the Content-Transfer-Encoding works when sending a file with the multipart/form-data HTTP POST action.

 

We are sending files via an API that must conform to HIPAA standards- it must be encrypted. 

 

We expected that setting the Content-Transfer-Encoding to base64, as seen in this capture, would do the trick.

 

However, this does not seem to be actually encoding the file contents, as can be seen by this snip from Wireshark showing the setting for base64, but plaintext is visible in the packet.

 

What can we do to set the file to actually be base64 encoded?

0 0

Answer

SELECTED ANSWER
replied on March 6, 2019 Show version history

That won't add any additional protection. Wireshark will probably still recognize the base64 and show you the plain text version. Even if it wasn't immediately decoded, it's pretty easy to spot a base64 encoded string and reverse encode it.

HIPAA only requires encryption, which the HTTPS connection will provide you. There is no additional benefit or protection to be gained from adding additional encoding. You need to draw a distinction between encoding and encryption. Encoding is simply a readable alternate representation of the data, whereas encryption is actually preventing it from being read.

If you really wanted to, you could use a script activity to encrypt the document using SHA or something. However, this would require that you share keys with the other party and that they have the ability to add a decryption step on the other side. I wouldn't recommend this, since it adds additional complexity and failure points, and doesn't really add any additional safety. Stick with an HTTPS connection, and you'll be fine.

2 0

Replies

replied on March 6, 2019

Base64 encoding is not an encryption scheme. It's simply a way to encode binary data in a text stream to make it easier to transfer and store for various scenarios. In your screenshot, Wireshark is showing you the encoded version on the left, and the decoded version on the right.

The best way to ensure that your file transfer is secure is to make sure that you are communicating with an HTTPS endpoint. This will allow both ends of the connection to negotiate encryption, and secure the transfer.

0 0
replied on March 6, 2019

Devin,

I realized after hours last night, that the dialog for headers isn't an active setting, but a passive label for the POST call. You can't slap a 'puppies' label on a box of kittens and they turn into puppies. 

We are using HTTPS for the calls, we just wanted to add an additional layer of security on the information. I suppose in order to do that, I'll need to get the SDK and perform a base64 conversion on the document itself before adding it to a HTTP POST.

Thank you

 

0 0
SELECTED ANSWER
replied on March 6, 2019 Show version history

That won't add any additional protection. Wireshark will probably still recognize the base64 and show you the plain text version. Even if it wasn't immediately decoded, it's pretty easy to spot a base64 encoded string and reverse encode it.

HIPAA only requires encryption, which the HTTPS connection will provide you. There is no additional benefit or protection to be gained from adding additional encoding. You need to draw a distinction between encoding and encryption. Encoding is simply a readable alternate representation of the data, whereas encryption is actually preventing it from being read.

If you really wanted to, you could use a script activity to encrypt the document using SHA or something. However, this would require that you share keys with the other party and that they have the ability to add a decryption step on the other side. I wouldn't recommend this, since it adds additional complexity and failure points, and doesn't really add any additional safety. Stick with an HTTPS connection, and you'll be fine.

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.