Authenticating users for website

M

Mr_Superstar

[H]ard|Gawd
Joined
May 1, 2000
Messages
1,157
Hi. I've recently decided to develop a website as a personal project. I will be creating a website, and I wanted to know what the best way to store user authentication details.

I've seen a few examples that use a 'session' table that stores the session ID, the username, and the IP address.

My question is that are stale sessions a big problem with this scheme? Changing IPs and people not 'logging out' lead to excess rows being left in the table that will never be deleted. Is this really a problem?

Are there better ways to store/prove authenticated users?
 
sessions usually have a garbage cleaner that wipes those outdated rows you are talking about. and if they dont, then you could just as easily write one.

i wouldnt know of any particular "better" ways, but if you're talking about more secure ways to store authentication then there are definitely much more secure ways to go about handling this. for most projects that dont involve money transfers, what you are describing sounds fine.
 
The only problem with that is, what will you compare the credentials to in order to determine if they're valid or not? Sessions only last for as long as the browser is open. You'd either need a file with a list of username/password combinations, or a database. The problem there becomes security...a file like that is a serious target, and databases can be compromised. So one way to do it is with an MD5 hash...when your user registers (or you set up the user) the password gets hashed. When the user tries to login, his/her inputted password gets hashed, and then compared to the stored hash. They match, and a session variable is set to allow you to continue. If someone gets the list of usernames/passwords, it's useless to them (MD5 being a one-way sort of thing).
Pro:
The actual password isn't stored on your site at all.
Con:
If someone loses their password, there's no way to get it back; you have to make a new one.
Of course, MD5 hashing and comparing things means server-side scripting...PHP. .NET, ColdFusion or other means. Hope this helped!
 
O[H]-Zone;1030568744 said:
The only problem with that is, what will you compare the credentials to in order to determine if they're valid or not? Sessions only last for as long as the browser is open. You'd either need a file with a list of username/password combinations, or a database. The problem there becomes security...a file like that is a serious target, and databases can be compromised. So one way to do it is with an MD5 hash...when your user registers (or you set up the user) the password gets hashed. When the user tries to login, his/her inputted password gets hashed, and then compared to the stored hash. They match, and a session variable is set to allow you to continue. If someone gets the list of usernames/passwords, it's useless to them (MD5 being a one-way sort of thing).
Pro:
The actual password isn't stored on your site at all.
Con:
If someone loses their password, there's no way to get it back; you have to make a new one.
Of course, MD5 hashing and comparing things means server-side scripting...PHP. .NET, ColdFusion or other means. Hope this helped!
Click to expand...

My 'users' table will have a password column hashed by SHA-256. I'm not really worried about users forgetting their password, generating a new one and sending an email to the user is simple enough (although not the most secure system).
 
I guess the first question would be what language are you doing this in? That will definitely have an impact on the method of authentication.
 
redwolfe3 said:
I guess the first question would be what language are you doing this in? That will definitely have an impact on the method of authentication.
Click to expand...

I thinking about doing this in Java and using Tomcat as the servlet container. If I go this route, my work is basically done because I can use container managed security to handle the sessions for me.
 
You must log in or register to reply here.
Back
Top