I am creating a log in system. The easiest system would simply check a database for a log in and password, then same a session var which states login=true I am interested in other things that I can do to make it more secure. Here is a general list of things that I have already found. Feel free to use some of these items or list to one that I have not mentioned. I'm really interested in finding obvious security holes that I am not covering.

  • one-way encode passwords in the database
  • save and validate the users IP address
  • save a variable in the session that changes every 10 minutes (instead of login=true).
  • Use the database instead of sessions.
  • Use JavaScript to validate that the user is using a browser.
  • Lock an account after 5 login fails.
  • Use https
  • 3
    Hello there! I have made a very basic simple search in google and I have identified dozens of articles with the necessary information to build a secure log-in system. I belive your best option will be to read them and then ask for specific questions instead of a full security design. Have a look: google.es/…
    – kiBytes
    Mar 20, 2014 at 13:40
  • Please use existing authentication libraries available for your language. Don't reinvent the wheel.
    – schroeder
    Mar 20, 2014 at 15:17
  • I'm a little torn here. I'm getting great, useful answers to a troubling question.
    – Hoytman
    Mar 20, 2014 at 17:52

2 Answers 2


This question is extremely broad, but I'll point you towards some information that might help:


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:

  • Use cookies for your session IDs, link sharing won't lead to session hijacking.
  • 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 /tmp.

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.

Use JavaScript to validate that the user is using a browser.

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.

  • Locking an account after 5 failures also opens up a 'griefing' vector for malicious users, deliberately failing the password so the actual user cannot log in. If you must lock, lock by IP and set it to automatically unlock after X seconds/minutes. Mar 20, 2014 at 14:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.