in reply to Re^3: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
in thread In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?

(First and foremost, thank you for your discussion, you make sense- your comments have already helped me.)

Indeed what is being generated are tokens, the client chooses one and sends to server.
It seems I am using cryptography to identify that the tokens are generated by the server and for this authenticated session.

What other ways could I prove that the tokens *were* generated by the server?
To address your very dead-on point:

So you don't need crypto at all -- to validate something, just check whether it was something you previously generated.

In my case simply matching their session id, to the key in session and decrypting the token.. I am not exaclty *proving* it was generated by the server.

There *is* a way to come close to guarantee this?

( I don't see how else it could be possible?! Once the tokens, selections reach the client, there's nothing that I can do to control what they do with the data. All I can think of is that the server would keep a lookahead list of *possible* requests that would come next? That seems wild and whacky. )

  • Comment on Re^4: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?

Replies are listed 'Best First'.
Re^5: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
by clinton (Priest) on Jul 03, 2007 at 13:53 UTC