Re: Authorization question, w/ "Windows" authentication mode

That's exactly right. Essentially, things like cookies and query strings
need to be treated as input. If you want to ensure that they have not been
tampered with, then you typically want to encrypt (which doesn't ensure
tamper resistance, but it make it difficult for a hacker without the key to
create valid data that has been altered) and/or use signatures/MACs (which
do provide tamper resistance, but do not provide privacy of the data).

The System.Security.Cryptography namespace includes features for encrypting,
signing and adding MACs. You would probably want to find some samples of
how to use these things rather than figuring out how to code them yourself,
as there are some pitfalls and many developers struggle to implement these
things correctly.

Note that this is not absolutely required, but you can't really consider
your system secure if you are taking input from the user that has not been
properly validated. That is web security 101.

Joe K.

Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
<matt@xxxxxxxxxxxxxx> wrote in message

Joe Kaplan (MVP - ADSI) wrote:
Yes, that is normal. To avoid a database hit, you can use the cache or
session state or perhaps a cookie (if it is properly MACed or encrypted
prevent tampering).

thanks, joe. ill likely store them in the session or a cookie. i did a
quick google on MAC -- is this message authority checking? an article
(non-.NET) mentioned an MD5 algorythm.. know of any nifty .NET code for



Relevant Pages

  • Re: Encryption *As Recorded* can anyone give me a clue?
    ... As the audio comes in to drive, the stream itself needs to be encrypted to ... What I receive at the far end of the media is what was sent. ... then you will have to encrypt it at source ... The 'Integrity' component will provide the tamper proofing and tamper ...
  • Re: cookie encryption/security
    ... user information off of that in the differnt pages of the site. ... The cookie is created on login, and is separate from the authentication cookie. ... to persist the session in SQL server or State Server instead of InProc. ... There is a possibility that someone could steal the cookie (or tamper one) so what you can do is to store in your servers other information about your client This way the malicious user will have to tamper the IP apart from the cookie, this doesn't eliminate all the risk but at least it will be much harder. ...