ASP authentication

Allright, I've actually looked on the forum for this and all I get is threads describing problems with SQL authentication and so on.

What I am looking for is much different.

I gave users the ability to log onto my website. You sign up, your password is stored in the DB, and you can login at will to do whatever you need to do.

This is how it works:
a). New User signs up -> info is stored in SQL.
b). Users logs in -> Password and username stored in cookie
c). User hits restricted page -> Password and username pulled from cookie and checked against database. If not valid, redirect, if ok proceed with loading content.

Now, this for some reason seems really lame. For once, I'm using SQL resources every time the user hits a restricted page. 2, I'm storing the password and username in a cookie.

ITs mostly the second part im worried about. I would like to get away from storing passwords in cookies, is this a possibility?

Quote:

---

Originally posted by invitro
I would like to get away from storing passwords in cookies, is this a possibility?

---

Its not safe to use password in cookies, instead store the password hash in the cookie and compare the hash. There are MD5 hashing algoirhtm available for asp, search for them you will find them.

In fact it is not advisable and safe to save the password even in the database, you should store the hash.

Hope this helps.

I suppose I don't understand the concept of hashing. I found a very nice algorithm off the net... so, when I encrypt the txt it returns something like this:

CC96C3F112775B6B0C8A083F863D3660

Now, what do I do with that? How do I reverse it. OR, is hashing used for something else like making a key of some kind rather then making up the encryption itself?

It looks to me as if hashing is just generating a unique value to that specific word... oh I think I get it.
So, basicaly, if i store that in a cookie, I can compare that to the hash in the database every time i load a page... the password will generate a unique hash for that specific word. SO, even if i store that in the cookie, anyone can get the hash, but wont be able to do anything with it anyway because if they try putting it into the password field the server will generate a hash of the hash which will be different then the hash in the dbase... the original hash can only be obtained by using the original password.

ah, smart. Did i get it, am I at least on the right track?

Quote:

---

So, basicaly, if i store that in a cookie, I can compare that to the hash in the database every time i load a page... the password will generate a unique hash for that specific word. SO, even if i store that in the cookie, anyone can get the hash, but wont be able to do anything with it anyway because if they try putting it into the password field the server will generate a hash of the hash which will be different then the hash in the dbase... the original hash can only be obtained by using the original password.

---

Yes thats exactly what a has is used for. Hash is simply a value which is derived from a intial value, but it can not be and impossible reverse back to the original value. Thats why it is regarded as "One Way Hash".

Like you said we simply compare the stored hash value of the password against the hashed value of the one they typed in. This technique can prevent some one stealing a online data base and using the user's password to log into the account.

Most companies does not store the actual password and Credit Card information on database instead store the Hash.

If you need MD5 hash module for ASP let me know.

In your case you could encrypt the password with any decent algorithm and store it in the cookie that should be enough to prevent the average users from reading the cookie and getting hold of the password.


Hope this helps.

Danial

Danial to the rescue, again.. thanks man you've helped me out tons. I got an algorythm from the internet already and it works great. Wow, thanks for suggesting the idea to me.

So, not being able to go back is 'theoretical' right... there has to be a way. Because if there werent, wouldent that be the ultimate encryption... oh wait, its not encryption though... because you cant go back, so sending it would be useless... ok, gotcha.

Thanks !

Quote:

---

Originally posted by invitro
Danial to the rescue, again.. thanks man you've helped me out tons. I got an algorythm from the internet already and it works great. Wow, thanks for suggesting the idea to me.

So, not being able to go back is 'theoretical' right... there has to be a way. Because if there werent, wouldent that be the ultimate encryption... oh wait, its not encryption though... because you cant go back, so sending it would be useless... ok, gotcha.

Thanks !

---

Note, theoretically(Mathmetically) it is possible to get the original string back, but with the current computing power available it is considered computationally in-feasible.

Yes a hash function is not "Encryption". The use of encryption and hash function is different, though encryption algorithm uses "one way hash" for keys also public key cryptography uses "one way hash".


Hope this helps.

Danial

:wave: