Yes, in the end to be "logged in" is equal to having set a session variable. So your question basically comes down to session security. Here are a couple of things you might want to check and/or consider:
- Ideally use HTTPS, so that sessions cannot easily be hijacked in open Wi-Fi environments.
- Make sure Cross-site request forgery doesn't work on your sites.
- Make sure you are not vulnerable to Cross-site scripting attacks, or at least make use of the
HttpOnly attribute of Cookies.
- Make sure that your session IDs are not predictable and cannot be fixed to predefined values by the user
- Make sure your session data is not (easily) accessible to others. For instance in virtual hosting environments it could be easy for others to read or even manipulate your session data, which usually is a simple file within
Obviously this is not a comprehensive list, rather a few things that just crossed my mind.
one-way encode passwords in the database
That goes without saying! But simple one-way encoding (i.e. hashing) is not enough these days. Look into real key derivation functions, e.g. PBKDF2 and bcrypt. These are designed to dramatically slow down brute force attacks.
Use the database instead of sessions.
What do you mean by that? The database doesn't know anything about HTTP.
Cannot be done.
Lock an account after 5 login fails.
Although a noble idea, it is completely unpractical for most sites. What do you do with accounts that are locked down? Are you going to offer phone support? How do you authenticate users on the phone? What you could think about is a timeout, which would make it unfeasible for attackers to even try to brute force passwords.