User Authentication

[richiejones24]

I have had a problem with people attacking my site and trying to gain access to users accounts so i beefed up security, however now users are complaining they keep getting logged out.

 

Here are the variables i use to validate the users and i dont want to strip them down any more can anyone give me any ideas for changing them so its still secure but not so strict as to keep logging the users out?

 

1. Username & password is encrypted into a cookie and verified on every page they visit.

2. There ip address is recorded on login and is checked against there current ip, on every page they visit via MySql.

3. When the user logs in a unix time stamp (mySql) is generated an updated of every page they visit and if it has not been updated in the last 60 mins the user is logged out.

4.I also generate a random key which is stored in the DB and is passed on every page via GET.

5.If a user tries to login and fails an email is sent to them and if 3 unsuccessful attempts user is locked out for 30mins.

 

 

[Muddy_Funster]

If you bind the session to their IP+account I dont see why you would want/need to time them out every hour.

[Psycho]

I'm no security expert, but I think you may be taking the wrong approach. Several of the things you are doing have no value from my perspective. Each security measure you implement should have a purpose. Can you elaborate on what each of those methods is supposed to guard against?

 

You say that users are trying to access user accounts. How are they doing this? Are they randomly attempting different username/password combinations? Have they actually gotten in? If these malicious users have already gained a user's credentials the processes you have will do nothing.

 

Here are my observations on those processes:

1. Username & password is encrypted into a cookie and verified on every page they visit.

If you want your site to be secure then you should not store any sensitive information in a cookie. Even if it is encrypted you are sending the information over the wire where someone could capture it and attempt to decrypt it. And, why do you need to validate their login credentials on each page load. If the credentials passed once wouldn't they pass again (unless the user was disabled/deleted). Instead just store a user ID in a session variable upon successful login. Then on each page load check that that value is set - if so the user was successfully authenticated, no need to reauthenticate. but, if you need to check for disabled/deleted you could use that value to do that check.

 

2. There ip address is recorded on login and is checked against there current ip, on every page they visit via MySql.

Storing the IP is fine, but decide what you are using this for. I don't see a need to check it on each page load since you can track the user via sessions. One possible use of the IP address is to prevent concurrent logins and/or provide a higher level of scrutiny at long. For example: 1) If you are tracking a user's activity on the site you could prevent someone from logging into the same user account while that account is logged in. Now, with a web app you can't really know if the user has closed their browser so you could just implement a time period. So, if the user was last active within the last 20-30 minutes don't allow them to log in again. 2) You could also use the IP address at the time of login to track the IPs that the user has used. So, if a user attempts to log in from a different IP address than they have used before you could require the user to go through an additional level of security. Then once authenticated store that IP. I know it used to be common for users to always have different IPs from their ISP, but I'm not sure that is the case anymore. If so, it could be a burden for some users.

 

3. When the user logs in a unix time stamp (mySql) is generated an updated of every page they visit and if it has not been updated in the last 60 mins the user is logged out.

I see no problem in keeping track of the user's activity since you can use that for other purposes (see #2). Also, 60 minutes seems like a long time to be inactive. But, I don't know what your application is used for. But, I suspect that if users are getting logged out before the 60 minutes it may have something to do with this implementation.

 

4.I also generate a random key which is stored in the DB and is passed on every page via GET.

I don't understand what the purpose of this would be. You can already track the user through session data.

 

5.If a user tries to login and fails an email is sent to them and if 3 unsuccessful attempts user is locked out for 30mins.

Personally, I would not email the user every time there is a failed attempt. It could look bad on you, the provider. Notifying them after the account is locked makes sense though. however, I would log each failed login and perhaps send an email to yourself (or whoever should be monitoring security) when certain criteria are met. What that criteria is would be up to you. But one example would be attempts to log into multiple accounts from the same IP within a certain time period.

[scootstah]

You are needlessly accessing the database way too much. Like Psycho said, you  can do mostly everything with just sessions. The sessions aren't going to change, so they are perfectly reliable.

 

User authentication is risky business. It's easy to get wrong, easy to inadvertently create security holes. If you don't know what you are doing, it is best to use someone elses library that has already been under extreme scrutiny. Maybe take a look at how some of the popular frameworks do authentication. Here is an example to get you started: Ion Auth Ion auth is pretty simple, so it shouldn't be too hard to pickup the logic.