3

I need help determining how safe the login is. First of all, I have been reading this:

The Definitive Guide To Forms based Website Authentication

It's really well written, great information most of which was either entirely new information or more detailed than I previously knew. However in my situation, I can't decide if it's helpful or not.

The problem is:

  1. I have a login that will be used by 1 - 3 people max, with their passwords distributed in advance. The login itself will be online, but will function more like a closed network login, not being available to the global public visiting the website with clickable links to it -> (but with modifying the address bar to add /admin so that admins can access it.
  2. With that being done, the user experience for even a handful of people is necessary. I want to put a dreadful "Remember Me" so that while only they will use the login to access the admin page, they don't have to login everytime.
  3. The problem arises when a real situation today is to someone accidentally charge to the login or admin page. Either way since he/she isn't logged in, the page will forward him/her to the login page. For the global population that really went there accidentally, I will put a "Return to Home" link, but the concern is if that person tries to brutal attack the way in, or worse.
  4. I thought about IP FILTERS but don't know how good that will be, today it's absolutely no effort to change an IP ADDRESS. I thought about Session lock with DB values on login, but that would lock the entire login for X amount of time (and if the brute force continues, the admins will never be able to login, because the lock will re-activate after the X time with the brutal attacks). I thought about captcha, but wouldn't that counter the remember me?
  5. I don't like to false hope that nobody will even try to hack an innocent website, or spam the hell out of it. That is reality today. I just want to hear if you have a better way than what I think. If so please, tell.
Improve this question
0

1 Answer 1

Reset to default
3

  1. Security by obscurity is bad. While developing it act as if the login form was displayed to every user of your website.

  2. Remember to create the "Remember me" function in a way that does not store e.g. the password in a cookie. One choice would be having a random and unique login hash stored for the user. You then save the user id and this hash in a cookie. This prevents the password from being saved in a cookie and you can provide a "log out everywhere"-style button that simply changes the hash in the database and thus invalidates all "remember me" cookies.

  3. While also somewhat of security-by-obscurity you could simply return a 404 error in this case. No need for people to know that something exists even though they do not have access to it.

  4. Brute force attacks might be carried out by botnets so an IP filter alone is indeed not much help. So restricting the number of login attempts by account is the only valid choice. However, you can do this in a very user-friendly way by allowing 1-3 attempts without any captcha etc. and then require a captcha on every additional attempt. Of course locking the whole account for some time would be even better but then people could DoS your legit users. That captcha will not interfer with "remember me" - the restrictions would only apply to the Username+Password login but not to the cookie login. That's not an issue since you can simply use 40+ character hashes for this purpose and you can safely assume that those won't be cracked using brute-force.

Since you just have a few users you might want to consider using SSL client certificates for authentication in case those users are not likely to login from random machines. They'd install the client certificate/key in their browser and then simply select it when logging in - no need for a username/password anymore. And SSL is secure enough so you don't have to worry about brute-force attacks for now. However if your users are stupid enough they might export the key without encryption and store that unencrypted file on their PC. But then again, this kind of user would also have a passwords.txt file on their desktop...

Improve this answer
7
  • Thanks a lot. I've be re-reading what you said like 5 times. 1. Right 2. Got it, random token 3. That is a great idea. I think a simple if/else will suffice 4. Right, even 20 characters would take years to crack, for 40+ its veerry long. But the DoS is a considerable threat. Will the 404 work against DoS, if they can't get to the login page? Yea, its for the worst type of users, but certificates won't do because all of them have home/work computers + phone with internet.
    – David Law Drakulovski
    Sep 5, 2012 at 16:06
  • DoS is always a problem if you have per-account logs after invalid logins. That's unrelated to any status code you return.
    – ThiefMaster
    Sep 5, 2012 at 16:14
  • I am not getting it, obviously - explain the DoS threat. They don't need the login to spam the server yes, but they won't atleast spam with login requests. Or that's not the logic?
    – David Law Drakulovski
    Sep 5, 2012 at 16:42
  • I was talking about DoSing the user account - i.e. try logging in with multiple passwords to prevent the actual user from using his account.
    – ThiefMaster
    Sep 5, 2012 at 17:23
  • I don't know if are on the same page but - the website doesn't have any logins for normal guest users. The main login is also not available to them. The only threat guest user can attempt is the search. And that is protected from SQL injection. So I don't know how will those DoS users find out the username of the admin, or even find the login, especially if its hidden with the 404. Once again, I fail to understand.
    – David Law Drakulovski
    Sep 5, 2012 at 17:37

You must log in to answer this question.

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