So i'm in the process of making a login form for users, and I'd like to make things as secure as reasonable. It's a consumer site, not a financial site, but seeing how I myself like things to be secure when I login to a website, I try to keep things as secure as possible in my form.

Steps I have taken so far:

The site has a ssl certificate with server set to support strongest encryptions whilst still allowing the bane of the internet to access our site(we have some aged customers, fine year) enter image description here

The password is hashed with bcrypt.

For the login form i'm using a csrf_token generated by hasing bcrypt from

  • hostname
  • user ip
  • session_id
  • user_id

user id is generated for each user that visites on the basis of GUID when they are not logged in yet, this is stored in the session on first site access and not visible to users.

The csrf is not re-generated for each for each page request because of history issues and like stated, we are not a financial institution and for any plugin it's trivially easy to harvest any csrf tokens. So that's a step I don't need to take to secure the page(what i've read on this site anyways)

cross site scripting is disabled.

added X-Frame-Options: SAMEORIGIN headers

The question: Are there any other steps I can take/need to consider that will secure the login/user interaction process?

  • 1
    Your question in its current form seems to be too broad for this site. Try to focus your question on one specific aspect instead, eg "how to generate csrf token" (I'm a bit surprised that you do not just randomly generate it, but construct it from partially known data instead), "when to regenerate csrf token" (likely a duplicate), ...
    – tim
    Commented Feb 3, 2017 at 10:46
  • Well, I tried looking at all the things, thats how I got to ssl, bcrypt for hashing and using a csrf token, but I'd like to know what else i've missed. The guid is also random as due to when not logged in it's consistent from a guidv4 + session_id, which is entirely random and pretty collission resistant. Commented Feb 3, 2017 at 10:53

1 Answer 1

  • Long password with compensation of number, alphabet and symbol.
  • User-names should be unique
  • Restrict the number of failed login attempts to prevent brute force attack and temporary block the user for verification
  • Don’t allow error message in case of failure to give use or hacker hint
  • Credential should transmission in secure connection
  • Secure the change password functionality
  • Generation of CAPTCHA Image
  • passwords i'm showing the users a password strength meter together with how long a hacker would need to crack the password. If they choose unsafe it's their fault(need to accomodate simplicity and ease of creation unfortunately) Number of failed login attempts is good. Captha image I can't do because it would hamper the user interface. Might consider captha if more than 3 failed login attempts. Commented Feb 3, 2017 at 12:06
  • 1
    at the number alphabet and symbol I have only one thing to say: smarthorsebatterystaple Commented Feb 3, 2017 at 12:48
  • Be aware that restricting failed logins too much opens you up to targeted DoS attacks. I've had websites lock me out for 12 hours after the 3rd failed attempt. Not good for usability. 60 seconds after 3rd attempt, 10 minutes after 20 attempts, etc. is more than enough to make brute forcing unfeasible, give you plenty of time to catch it happening via logs, and not interrupt legitimate users from logging in.
    – Dan
    Commented Feb 3, 2017 at 14:39
  • *correct horse battery staple (remember the part on mnemonics? wow that was self-referential)
    – J.A.K.
    Commented Feb 4, 2017 at 20:51

Not the answer you're looking for? Browse other questions tagged .