Encrypting data across an already encrypted connection

[drebo]

I read somewhere some time ago that encrypting data across an encrypted connection actually caused that data to become less secure.

Here's the situation: I built an online bill payment application for a customer. Anyway, at the verification page, where the customer checks to make sure his/her information is correct, I pass all of the information as a single hidden form variable after concatenating the data together with a certain token and then encrypting it using AES encryption. The idea, obviously, is to avoid any kind of plain-text display of the credit card information in the source of the page. The entire application runs over an SSL connection.

So, my question is has anyone heard of encrypted data being less secure than plain text over an encrypted connection? I could swear I've read it before but I can't seem to find the text again.

 

[DnetMHZ]

It may be slower/more overhead, but I don't see how it would possibly be less secure.

 

[Aberforth]

Since the data is transmitted over SSL - extra encryption is not needed, but it also depends on the cipher strength and commercial e-commerce applications need atleast 128 bit.

I used your method for my software protection app but it was only added as a extra security because it definetly slows down the entire process. But SSL is based on public key encryption to stop hackers from snooping into a transaction, when the data arrives- it is upto you. Now you might want to encrypt the customer records in the db with a different encryption but definetly NO double encryption during transmission.

When sending data you can make use of RADIX 64 algorithm to encode data as it is more compatible than plain text (see my signature).

 

[drebo]

I know how SSL works. As I stated in my original post, the idea behind encrypting the data before sending it back to the user was not for transitory security, but rather to obscure the data at the customer's end, so that it was not available as plain text in the source of the page on the customer's side.

Transitory, I have a business-class 128-bit SSL certificate that's insured for a lot of money.

As far as performance goes, this is application is running on a dedicated server, so performance is not an issue. The entire issue stems from the fact that ALL data had to be transitory. I'm not storing any of it on the server. So I can't just write the data to a database and pass the index value with the validation page. I have to pass everything. Indirect customer requirement (function of budget).

Hence my concern. I want to know if I am inadvertantly making the data more vulnerable in transit while trying to make it more secure at the user's end. I seem to have remember reading something about that some time ago, but maybe I'm just crazy.

 

[Aberforth]

No you are not making data more vulnerable but your method isn't generally approved as standard procedure, there is no point in doing it and also it raises privacy issues from the client end as they generally like to know what data is being sent. However if you only want to obscure the data you can use RADIX encoding.

 

[DaveSimmons]

Hence my concern. I want to know if I am inadvertantly making the data more vulnerable in transit while trying to make it more secure at the user's end. I seem to have remember reading something about that some time ago, but maybe I'm just crazy.

It might have been a problem with some specific, simple cipher like letter substitution. Or letter substitution plus simple compression (like Huffman that would pre-sort the most common letters).

Or it might have been something about the buggy / broken encryption in WEP for wifi.

I can't recall reading anything about nested strong encryption getting weaker.

and also it raises privacy issues from the client end as they generally like to know what data is being sent.

This usually only applies when an application phones home, not on a web page that only has the information supplied by the customer.

One advantage of using the AES is it makes it harder for robots to use the page. (They may want to use it if they can't steal the medicine from old people.)

 

[Aberforth]

Originally posted by: DaveSimmons
This usually only applies when an application phones home, not on a web page that only has the information supplied by the customer.[

You seem to assume that there is no means of sending data other than the client entered information.

 

[DaveSimmons]

An ActiveX control, Flash or java applet won't need to send information using a hidden form variable, they could do a direct GET themselves.

Do you have a link to some style guide saying form variables should not use encryption? I've never seen this mentioned before.

 

[Crusty]

If you are storing private user information in plain text form fields, that's a security problem. For example, if I was going through the motions of checking out through an online shopping cart and I put my CC info into a form and click next, I would NOT want my CC info to be in plain text embedded into hidden form fields on the next page. Even though the page data is sent over SSL to my browser, that data is visible in plain text once the browser decrypts the page. On top of that, if the page is cached then it's going to be stored on your HDD/RAM somewhere.

 

[drebo]

Originally posted by: Crusty
If you are storing private user information in plain text form fields, that's a security problem. For example, if I was going through the motions of checking out through an online shopping cart and I put my CC info into a form and click next, I would NOT want my CC info to be in plain text embedded into hidden form fields on the next page. Even though the page data is sent over SSL to my browser, that data is visible in plain text once the browser decrypts the page. On top of that, if the page is cached then it's going to be stored on your HDD/RAM somewhere.

Hence my reason for encrypting it before embedding it in the page as a hidden form field.

However, the consensus seems to be that encrypting data twice doesn't seem to be an issue, so I'm OK with that.

 

[smack Down]

It can be a security risk. It really depends on the encryption used and how good of is your random number generator. Most encryption can be decrypted using the same function as encryption so if you apply encryption twice with the same key you are in fact send your data in plain text. If you use a completely random key then encrypting twice will be equal to or better then encrypting once with any random key.

 

[degibson]

I don't think you're adding any security risk by dual encryption. In fact, I think you're making your client's customers more secure by obfuscating their information on their local machines. Good thinking.