views:

80

answers:

3

I have a form with certain elements, input boxes, check boxes etc. I need to encrypt the names of these input boxes and check boxes. I'm currently using a Rijndael encryption/decryption method through c# however this is making the encrypted names too long to be passed in a post. Is there a better way to get decent encrypted names? my purpose is to have the names encrypted before the post happens so if someone views the code behind the names are already encrypted.

A: 

You might be better of mapping the names to random values on them server-side.

[lkjgh] = 'username';
[hjsaf] = 'email';

If you remap on every request, looking at the code will not reveal anything of value.

Still makes me wonder, why this requirement? Usually, SSL prevents eavesdropping just fine.

Jacco
Mapping the names is an option I'll look into however my element names are a bit dynamic. I was wondering if there were any forms of 'short' encryption that could be used to produce small nonsensical strings than cna be decrypted at server side.
William Calleja
A: 

If you worry about the possibility that someone relates the input name with what the value it carries is, why not just use guids instead of meaningful variable names?

Peter Lillevold
Thanks for the suggestion but I need to retain my element names in their entirety. A GUID would not allow me to have dynamic element names or rather I'd have to come up with new GUIDs for every form I will create and I'm foreseeing that I'm going to need a LOT of forms and a LOT of different elements.
William Calleja
You could easily generate guids and store these server-side, perhaps in an application-state dictionary that maps name to guid. This will allow for dynamic names. But: if the dynamic behavior is such that you generate new names for each request, I would not recommend my approach as the dictionary would probably grow over time.
Peter Lillevold
+4  A: 

Just what do you intend to accomplish by doing this?

  • It's not going to stop anyone from analyzing the form or submitting spoofed data. If they look at the page source and see <p>Email: <input type='text' name='skhge,f'></p>, then it's going to be quite clear to them that "skhge,f" is the name of the email field, so they can just submit spoofed data under that name instead of "email".

  • One of your responses to comments on the question seems to imply that you're concerned about the form being intercepted as it is sent to the user. If so, use SSL. It encrypts traffic in both directions, so you're covered against any interception that way, while just hiding the field names would provide no protection at all. (My first point applies equally to an eavesdropper as to the final intended recipient of the data.)

  • The only possible scenario I can think of where this might be of any benefit is if you're worried about someone building a bot to submit forms to you, but, even then, it's the wrong approach - if you're encrypting the field names, then they'll remain the same every time you send the form, so the bot will just be written to submit "skhge,f" every time instead of "email".

    To foil a bot in this way, you'd need to submit random field names with every form, not encrypted names, and your responses to the suggestion of using a GUID indicate that you don't want to maintain a 'field name -> meaning' map for every form sent out. Maintaining such a map is the only thing that would slow down a bot writer and, well, even that wouldn't slow them down much. Unless you take exceptional measures to obfuscate your form layout and text content (such as those used by spammers in their attempts to slip HTML mail through spam filters), it would be easy for me, as a bot writer, to request a blank form prior to submission and correlate the textual labels presented to the user (e.g., the user-visible text "Email:") with the corresponding input field and obtain the correct field name ("skhge,f") that way.

So I'm not quite sure what your intended purpose is, but I am 99% certain that encrypting field names will not be the best way to do it - if it would even work at all.

Dave Sherohman
I'm not worried about bots but so far my key changes periodically for the 'nonesense names' of the fields is also changing periodically and yes, I don't mind anyone co-relating the nonesense names to what the fields represent. all that I need is a simple encryption system that allows me to change short strings into a nonesense value that can be decrypted at a later stage.
William Calleja
@William Calleja> **Why** do you need "a simple encryption system that allows me to change short strings into a nonesense value that can be decrypted at a later stage"?
Jacco
@William Calleja - You still haven't answered my primary question: What do you intend to accomplish by doing this? What benefits do you believe you will gain by encrypting field names, even though you acknowledge that it won't slow down any human who wants to obtain the encrypted information and say that bots aren't a concern? It sounds like you just want to add a bunch of complexity for no reason at all.
Dave Sherohman
I have solved the issue. I thank everyone for their input.
William Calleja