Skip to main content
P
PHRED-SE
Inspiring
September 22, 2009
Question

Encode and Decode, DES/DESEDE algorithm conumdrum

  • September 22, 2009
  • 1 reply
  • 2105 views

Because of a customer requirement, we cannot use Session variable to pass things like item ID values.  As a result, I’ve been using encrypted URL’s to do this kind of thing.  We discovered by chance the other day, that you could change the HEX encoded (using CFMX_COMPAT algorithm) URL values and change the item ID, which would let the user move to a place he isn’t supposed to go.  OOOOps.

I have been using the Session.SessionID as a basis for the key of the CFMX_COMPAT encryption for about 18 months now and no one has discovered this hole in the system, but I guess it is only a matter of time before someone does.  Today I tried to figure out how to use the DESEDE algorithm but the thing that has me stymied is how you pass are supposed to pass the key value across to the Decrypt code.  In all the manuals and all the examples they show only, they cheat; i.e., the work both sides of Encrypt/Decrypt process from the same form.  Well, you can’t do that when you are going across the URL bridge.  I suppose I could encrypt the DESEDE key that I generate using the generateSecretKey(“DESEDE”) using CFMX_COMPAT and then decode it across the other side of the URL bridge using the Session.SessionID, but this seems to be getting out of hand.

One other issue, I have to pass things via email between systems so I do have to pass the Session.SessionID value between different Cold Fusion systems, but I have come up with a way treat a passed in Session.SessionID value as a one-time, throw-away key.

Note: I can only get by using the Session.SessionID value because it remains the same throughout the user’s whole session and is not related to any particular item as it would be if I were still using Session.ItemID’s. 

As a stop-gap measure I am doubly encrypting the ItemID before I assign it to the URL.  After the 1st encryption I append a known string to the 1st encrypted value and then do my 2nd encryption:  url_DblStr=”#EnCrypt(#1stEnCryptStr#wxyz)#”.  After I’ve done my 1st decryption on the other side, I ensure that the “wxyz” string is still intact on the end of the 1stEnCryptStr.  If it has been changed, then I know that someone changed something in the URL and I can send them to a place where they can do no harm. 

So here is my simple question: How can you use DES/DESEDE/etc. algorithms, which seems to require you to use the generateSecureKey() function, when you can not directly share the key through Form or Session variables?

There must be a simple way to do this thing that has not occurred to me even though I have given it a considerable amount of though over the last 24 hours.

Thank you in advance for your help and suggestions.

:-}

Len

 

This topic has been closed for replies.

1 reply

A
Adam Cameron.
Inspiring
September 23, 2009

Is there a reason why you can't use the same encryption key across the board, and put it in an application-scoped variable?

What is the basis for the client requirement that means you can't use session variables?

--

Adam

P
PHRED-SEAuthor
Inspiring
September 23, 2009

Thank you for your reply.

An application scope variable would be even worse soltuion than a session variable solution because it would widen the scope even further..

The reason that we cannot use session variables is that the client has an old habit that they continue to use and will not abandon.  This is the use of the "ctrl+N" feature which allows the user to open a new window within the same session scope.  They then go into a different item in the new window. This sets the session.ItemID to the new ItemID.  When they go back to the old window and appear to be in the old item.  When they appear to be making changes to the old item, they are, in fact, making changes to the new item.  By using URL vars rather then session vars, the itemID's are contained within the seperate widows that they have open.  You can argue about how they should do what they do, but they are going to do what they want to do and I have to live within their world.

Using URL vars have worked successfully for almost 18 months.  It wasn't until we found this security hole that we questioned the methodology.  I think the double encryption method is going to work OK, but apparent sameness (the first few and last few characters of the encrypted values are always the same) of the encoded values is going to draw attention to the fact that there is some constant value in the generation of the encrypted value.  This constant is the Session.SessionID that I use as the key.  If I could go to the generateSecretKey() methodology, then each encrypted ItemID would be significantly different because each secret key would be different.

The only way I can think of to make the generateSecretKey() work would be to pass this key as an additional URL variable.  In order to do this, I would have to encrypt that value using the Session.SessionID as the key.  Since the two keys would be relatively the same length, then there would be a large variation in the results with each new secret key.  I think this would work, but every additional encryption/decryption slows down the transition.

Thanks again for your help.

:-}

Len

A
Adam Cameron.
Inspiring
September 23, 2009

An application scope variable would be even worse soltuion than a session variable solution because it would widen the scope even further..

Why do you say that?  An application scoped variable is maintained by the server, and requires no external data to be transmitted about the place (like with session or URL variables).  It's only your own code that has access to it.  For someone to illigitimately use an application scoped variable, they have to hack into your code, or your server.  In which case you have more important issues to address than wayward itemIds.

The reason that we cannot use session variables is that the client has an old habit that they continue to use and will not abandon.  This is the use of the "ctrl+N" feature which allows the user to open a new window within the same session scope.  They then go into a different item in the new window. This sets the session.ItemID to the new ItemID.  When they go back to the old window and appear to be in the old item.  When they appear to be making changes to the old item, they are, in fact, making changes to the new item.  By using URL vars rather then session vars, the itemID's are contained within the seperate widows that they have open.  You can argue about how they should do what they do, but they are going to do what they want to do and I have to live within their world.

It sounds to me like there's a pretty fundamental flaw in the way your app is architected if that's your problem.  In the scenario you describe, the itemIds shouldn't be in a shared scope anyhow.  If they were just in the form scope (where they belong) then you'd not have this problem.

I think the fix you are trying to effect here could possibly be done to fix earlier bandaids that were applied in the wrong place.

Using URL vars have worked successfully for almost 18 months.  It wasn't until we found this security hole that we questioned the methodology.  I think the double encryption method is going to work OK, but apparent sameness (the first few and last few characters of the encrypted values are always the same) of the encoded values is going to draw attention to the fact that there is some constant value in the generation of the encrypted value.  This constant is the Session.SessionID that I use as the key.  If I could go to the generateSecretKey() methodology, then each encrypted ItemID would be significantly different because each secret key would be different.

The only way I can think of to make the generateSecretKey() work would be to pass this key as an additional URL variable.  In order to do this, I would have to encrypt that value using the Session.SessionID as the key.  Since the two keys would be relatively the same length, then there would be a large variation in the results with each new secret key.  I think this would work, but every additional encryption/decryption slows down the transition.

I think the entire approach you're taking here is pretty poor, and you're just trying to exacerbate it.

All you needed to do in your original instance is to not have the item ID in the session scope in the first place, but transport it between relevant forms via a form field.  Of course there could be situations in which the user needs to maintain a hook into a certain item between forms, in which case a session variable is appropriate, sure.  And - given the way you have architected your app - this can lead to the confusion you mention above.  However it seems to me that this is reasonably easy to resolve by putting the itemID into a form field too, so if the user has switched away, changed the itemId via browsing to another one, when they submit the first form (which now has an itemId mismatch), you can predict what has happened, and act accordingly: you either advise them their session is corrupt, or simply go "right, well this is the form for form.itemId, not session.itemId,so I'll update the data for form.itemId, and possibly switch session.itemId back to that value too.

No need to horse around with encrypted URL variables or that sort of thing.

--

Adam

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices