I am currently re factoring one of my web applications and I was hoping for some advice on improving my security.
I'll note that the application is in ASP.net and the current implementation prevents me from using integrated authentication. This is also in no way an application that requires high security, I just like having my bases covered.
In the past I've stored the id and a token . The token is a hash of the user's ID + the user's Salt (reusing the value from the auth info) When a user visits the site the ID is checked against the token and authed accordingly.
It occurs to me that there is a big hole here. Theoretically if someone got their hands on a salt value all they'd need to do is guess the hash algorithm and iterate through the possible IDs until they got in. I don't expect this to happen, but it still seems like a mistake.
Any advice on how to properly confirm that user cookies haven't been altered?
By default, Cookie-based authentication does not have solid protection against attacks, and they are mainly vulnerable to cross-site scripting (XSS) and cross-site request forgery (CSRF)attacks. But, we can explicitly modify Cookie headers to make them protected against such attacks.
What is Cookie-based Authentication? Cookies are pieces of data used to identify the user and their preferences. The browser returns the cookie to the server every time the page is requested. Specific cookies like HTTP cookies are used to perform cookie-based authentication to maintain the session for each user.
The cookie allows the server to identify the user and retrieve the user session from the session database, so that the user session is maintained. A cookie-based session ends when the user logs off or closes the browser. Cookie-based session management is secure and has performance benefits over alternatives.
The way most web sites do it is to authenticate the use and if successful they send the browser a cookie to store and send in any subsequent requests. If an attacker were able to get hold of the token (before it expired) they will be able to impersonate the user.
Because of this the cookie and authentication process should always be carried out over a https session. The only realsitic way an attacker has to get hold of the cookie then is to intercept it on the end user's computer and if they are able to do that they can probably install a key stroke logger and get the user's password anyway.
As to what kind of token to use it doesn't matter so long as it's pseudo-random enough to make it computationally expensive for an attacker to guess. I myself use GUIDs. if you need extra information in the cookie apart from just a sessionid you could append a GUID to it and then probably hash or encrypt it just for a belt and braces approach.
The best way is to store a session ID as the cookie value.
Whenever user logs in, you create a record in database or some other session store with a random session ID. Put the ID in a cookie. When you see the cookie later, you can retrieve all user information from database.
This approach has following advantages,
If this doesn't work for you, try encryption. Hash would be my last choice. Hash itself is useless. You have to store user id and other information in a different cookie in clear. You ended up expose user information.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With