Authentication and Login

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?
 
if I was you...

forget about storing the IP address, if their IP address changes they will end up having to login again.

use a cookie, store the user name, and store and hash of the password.

then you can check the authenticity of the user, effectively logging them on each time. nobody could fake that cookie unless the stole the hash, or knew the password to create a hash.

(if you're not comfortable storing the hash that's in the database for user login then you might store a hash of the hash, or a specific hash that's salted differently to how you usually store the passwords.)


so I log in with username + password

in my cookie I get userID + hash of password

each time the page refreshes you check the DB to ensure that the userID and password hash match properly.
 
While using encrypted passwords, querying databases, and managing sessions, is a good starting point.

In modern web development, a widely accepted practice is to use token-based authentication, often with technologies like JSON Web Tokens (JWT). Tokens are securely generated on the server, encoded with user information and expiry, and sent to the client upon successful login.

The client then includes this token in subsequent requests to access protected routes. Server-side, the token is validated and decoded to identify the user. This approach provides a more secure and scalable solution than relying solely on cookies.

Additionally, always implement HTTPS to encrypt data in transit for added security.
 
Back
Top Bottom