ssc456
Fully Optimized
- Messages
- 4,280
Hey guys,
So I've done my fair share of websites over the years but I've never really touched upon logins and stuff.
How are they done?
.net Web Apps come with a default project that has a whole login manager and stuff which i'm sure will do the job but that is just using it i'd like to understand what's going on.
So let's say I create a login page and a username and password field and a submit and on submit it encrypts the password and queries the database using a stored procedure and comes back as successful. Excellent, I can then redirect the user to a "UsersPage".
The problem I have is if I now want to browse from UsersPage to UsersPage2 how do I check the user is still logged in?
Yes I know I can create a cookie, but that seems like a terrible idea.
If I create a cookie with a key of "Isloggedin" and a value of "True" then anyone could fake it and access the UsersPage.
If I create a cookie with a key of "SessionID" and store a GUID generated from SQL when the user is logged in as the value this a lot more secure but in the grand scheme of things still quite insecure.
It strikes is if you were able to steal someone's cookies folder and pop them on your machine you shouldn't be able to log in, even if I set the cookie timeout to a couple of hours this is still a potential exploit however it may be unlikely.
So I could take it a step further and put a SessionID combined with the Users IP address in a cookie but it strikes me as i'm still heading in the wrong direction?
How is it meant to be done?
I could authenticate the user, and store a SessionID on the servers memory which is a lot more secure and each time I flick from page to page I could check the SessionID?
What is considered the "proper" way to do it?
So I've done my fair share of websites over the years but I've never really touched upon logins and stuff.
How are they done?
.net Web Apps come with a default project that has a whole login manager and stuff which i'm sure will do the job but that is just using it i'd like to understand what's going on.
So let's say I create a login page and a username and password field and a submit and on submit it encrypts the password and queries the database using a stored procedure and comes back as successful. Excellent, I can then redirect the user to a "UsersPage".
The problem I have is if I now want to browse from UsersPage to UsersPage2 how do I check the user is still logged in?
Yes I know I can create a cookie, but that seems like a terrible idea.
If I create a cookie with a key of "Isloggedin" and a value of "True" then anyone could fake it and access the UsersPage.
If I create a cookie with a key of "SessionID" and store a GUID generated from SQL when the user is logged in as the value this a lot more secure but in the grand scheme of things still quite insecure.
It strikes is if you were able to steal someone's cookies folder and pop them on your machine you shouldn't be able to log in, even if I set the cookie timeout to a couple of hours this is still a potential exploit however it may be unlikely.
So I could take it a step further and put a SessionID combined with the Users IP address in a cookie but it strikes me as i'm still heading in the wrong direction?
How is it meant to be done?
I could authenticate the user, and store a SessionID on the servers memory which is a lot more secure and each time I flick from page to page I could check the SessionID?
What is considered the "proper" way to do it?