ASP.NET question

[Alphathree33]

So when a user logs in on my website, I give them a cookie

Username=TheirUserName

And I set it expiry date to a long time from now. I then use the cookie to determine whether or not the user is logged in.

I recently realized that this is actually a security flaw, because someone else could fake a cookie and log into any user's account so long as they knew the username.

This is my proposed solution, and I'd like to know if it makes sense:

I'll add a second hash value to the cookie:

Username=TheirUserName
Hash=17894728942abcd

And store the hash in the user database.

Now if someone tries to "fake" a login cookie, they'd have to guess the hash right.

Is this a good solution to this problem?

 

[DaveSimmons]

If you're just running the user name through a simple hash function your secret hash might be easy to guess and fake.

Private key encryption using something like blowfish might work, just change the binary results to a hex string.

 

[Alphathree33]

Originally posted by: DaveSimmons
If you're just running the user name through a simple hash function your secret hash might be easy to guess and fake.

Private key encryption using something like blowfish might work, just change the binary results to a hex string.

Okay -- thanks. As long as my general method is sound, that's fine with me.

(As a side note, I'm hashing the system time when the user signs in, so the hash gets regenerated every time. Perfect? No. But I don't think this could be broken without some effort.)

 

[kamper]

It doesn't need to be anything crazy, just a random string should be fine. But there's no point in using anything at all predictable, the system time could be guessed.

 

[Alphathree33]

Originally posted by: kamper
It doesn't need to be anything crazy, just a random string should be fine. But there's no point in using anything at all predictable, the system time could be guessed.

Scenario:

User A logs in with his username and password and gets assigned a hash based on the system time at that very instant.

User B is somewhere else, trying to hack into user A's account. Even if he knew how to generate the hash, and that the hash was based on the system time, how would User B know the exactly instant that User A logged in?

 

[bsobel]

User B is somewhere else, trying to hack into user A's account. Even if he knew how to generate the hash, and that the hash was based on the system time, how would User B know the exactly instant that User A logged in?

Easy, guess and generate all possible hashes from a time window near the expected login time. Better to use something like the timestamp as well as a site local protected secret.

 

[Alphathree33]

Originally posted by: bsobel

User B is somewhere else, trying to hack into user A's account. Even if he knew how to generate the hash, and that the hash was based on the system time, how would User B know the exactly instant that User A logged in?

Easy, guess and generate all possible hashes from a time window near the expected login time. Better to use something like the timestamp as well as a site local protected secret.

Okay, fair enough. But this is certainly non-trivial compared to simply creating a cookie with the person's username.

(I'm not building something for the Department of Defense here

HOWEVER, your suggestion is appreciated, and I will likely improve the hash generating algorithm as you suggest.

 

[kamper]

Originally posted by: Alphathree33

Originally posted by: kamper
It doesn't need to be anything crazy, just a random string should be fine. But there's no point in using anything at all predictable, the system time could be guessed.

Scenario:

User A logs in with his username and password and gets assigned a hash based on the system time at that very instant.

User B is somewhere else, trying to hack into user A's account. Even if he knew how to generate the hash, and that the hash was based on the system time, how would User B know the exactly instant that User A logged in?

Assuming B was sniffing the original login (ignoring the possibility of just seeing the password ), he could easily have a sub-second timeframe to try from.

You don't have to go DoD, but generating something harder than that is so easy

.NET must have a random number generator, just grab a number and hash it. Adding other crap onto your random number before hashing is easy and improves security. Do the time concatenated with the random number. Concatenate the users email (if it's not publicly viewable). Concatenate the password (although then you risk the danger of having the password reverse engineered out of the hash).

The key is to have at least some input that a cracker has no context for predicting. Adding more stuff just makes it a lot harder to crack.