(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. )
In reply to Re^4: In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
by leocharre
in thread In a web app, is using ssl, encrypting request data, and validating request data after decryption overkill?
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |