Hey people,
I have always made my authentication codes by checking if the MD5 + salt of the pass provided by the user in the form was the same as the one stored in the DB, and if it was, i saved a session variable called "status", equal to 1. The, he was logged.
I'm pretty sure this is wrong and insecure, but i never seen any other methods. Can you guys help me? :)
This is basically the standard tut for creating a quality object oriented login system in PHP. I think it covers most of the bases and is well thought-out It's also very close to the solution you're doing.
I'd agree with moving away from MD5 but also maybe stretching the hash by repeating it a few times. Some more thoughts on security:
A session check alone is vulnerable to session hijacking (AKA sidejacking), I'd store a unique id in the session and also store it in a DB record along with the users IP and browser UA string to help alleviate this to a certain extent (also see Firesheep).
If you're not using SSL to submit your login form then your password will be sent in plaintext (or if you're using Basic HTTP authentication it will be very weakly obfuscated not encrypted). I'd think about some client-side hashing system or using Digest authentication instead.
There is no easy fix for website security, so apologies for the long answer:
How do you identify the users after they have logged in? If it's with a Session ID in the URL then this can be read and the session hijacked. If it's with a standard cookie, again the cookie can be read and the session hijacked. This is regardless of the type of hash function used on the password.
To be secure, use SSL (or similar encryption) and set a session cookie using the secure flag.
The trouble then is you can only verify the user's identity over SSL. To avoid having to have all pages of a website served over SSL two session cookies must be used, one secure and initiated during a secure authentication (login) the other standard and initiated when the user first hits a non-SSL page. Any private or protected data must be served over SSL and the secure cookie checked on each hit.
Of course the session data should be stored in the database, not the cookie. Only a session ID or similar unique string should be used in the cookie.
This way anyone attempting to hijack an active session will only get as far as the non-ssl pages.
IP addresses can be spoofed, same with the user agent, so these should not be used as part of user identification. Also the user's IP address may change during a session (eg. behind load balancer, anonymizer, or some ISPs), resulting in logout.
Also beware of cheap SSL certificates. They are not all safe.
Unfortunately PHP's native session handling is not secure so good application design is essential.
When it comes to users' passwords, enforce the use of long (8 characters minimum) passwords that contain a mix of upper case, lower case numeric and symbol characters.
Also prevent brute force attacks by blocking users for a period of time after a certain number of unsuccessful log in attempts.
If you provide a facility to reset passwords via email, make sure you users know to protect their email accounts.
In truth nothing is 100% secure but we can get very close and these are the primary steps necessary to achieving that.
Of course security is relative and the lengths to which you should go to protect your users' data will depend on what the data is and how much of a target your site might be. If you are storing credit card details and it's a popular site, then security is paramount.
If you store credit card details then you will also need to achieve the relevant level of PCI compliance.