securing a web page

[manwhoeatsrats]

most of my work has been on a company intranet, so while security is an issue, it was not an extremely major one because of a series of fire walls.

 

I am now designing a program that will be used on the internet, and now security is a major concern.

 

the log in page I have setup does the following.

 

1.  asks for a username, if the username is not in the database, it gives a warning stating such.

2.  if the password is in the database then it compares the password typed to a md5 hash that is stored in the user table.

3.  if the password is accepted it sets a session variable of the username and access level user, admin ect....

4  if the password is rejected then 3 tries are given to try again. after that the account is locked, and the hash of a random 32 digit number is put in the password place.  each time someone tries that log in it changes again.  after 6 attempts the IP is banned from the site.....

 

my question is, what else can I do to make the site more secure, besides checking for session variables being set.  and am I going to far with the log in page?

[teamatomic]

You might want to consider only locking them out for 5-15 minutes or so. It will save you lots of resetting of passwords and unbanning of IP's. Corporate pin-heads are really clueless about remembering passwords.

 

 

HTH

Teamatomic

[akitchin]

first, whether the username or the password are wrong, give the user an ambiguous error such as "username or password are incorrect." this stop any user from fishing around until they find a username, followed by trying out the user's password.

 

second, it sounds like all of this is passed unencrypted. to make sure anyone listening in doesn't nab the password being passed in plaintext in the first login attempt, it might be wise to use SSL to encrypt client-server communication. and this goes without saying, but if storing the password in the session, store only the hash.

 

third, restricting the number of login attempts is a flimsy and annoying safeguard, in my opinion. sometimes i'll forget my password because i have several others floating in my head, and it takes a few tries to get the right one. if i get locked out because i try the wrong three passwords first, i'm going to be pretty pissed. furthermore, i don't think restricting to three attempts is really going to dissuade a would-be hacker. either they're well beyond simply brute-force attempts, or they'll just move onto another user.

 

finally, it might be wise to store the IP in the user's session and check it on every page. it's unlikely that the user's IP will change during that individual browsing session, and this helps to avoid session hijacking.

[manwhoeatsrats]

thanks for the advice. I had never thought of giving an ambiguous error messege.  that makes logical sense.  As for the IP address, once again a good idea.  I could acually create a row in a transaction table that stores the same values as the session variables I set, and each page compares the session variables to what is in the database.... 

 

oh and the password, I had not thought about putting it in a session variable I was just going to do the session checks based off of the user id...but if I am going to go through the the trouble of passing an ip address as well, I might as well pass the md5 hash as well. 

 

Thanks a lot for the help.  you guys got the old noggen grinding now. lol

[akitchin]

i'm not sure there's much value in storing the all of the session variables in the database - what would that achieve?

[manwhoeatsrats]

i'm not sure there's much value in storing the all of the session variables in the database - what would that achieve?

well not all of them.  I am talking the the IP address, hashed password, time of login, and username.