Securing Cookie Based Authentication

问题:

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?

回答1:

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.

回答2:

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,

1. It's very secure. Session ID is simply a random number. You don't have to worry about compromised key or salt.
2. The cookie can be easily revoked from server. All you have to do is to remove the session record and that renders the ID useless.
3. The cookie value can be really short.

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.

回答3:

Two ways:

1. Encrypt it with a Symmetric algorithm (AES).

This is good because it lets you decrypt it; but it may be argued that you don't need to decrypt it (depending on what else you store in there).

2. Hash and Sign it. Again this uses a private key, so even if someone knows the exact contents, they can't reproduce the hash, because they need the private key.

I'd probably (and have previously) go with option #1.

回答4:

why not only store the hash in the cookie, or any other pseudorandom number? Then check against the database to get the user ID.

Other things: Make the cookie http only, ie cannot be set with javascript If it is an option, make it only be transmitted with https data