1

This question already has an answer here:

We have an application where we are using OS users for authentication and using native OS libraries for authentication of that user credential. We have implemented an account lockout functionality where we can lock the user attempts after configured number of attempts.

Actually, Windows OS libraries does not return the difference between invalid credential authentication attempt of fake user attempt so that's why we have to insert such attempts in DB for account lock. But on unix platforms we used to get the specific return code if user does not exist in system and we only audit such attempts and does not insert the record in DB for avoidance of DDos attack. But now they want same behavior for *ix platform.

So my question what do you suggest from security perspective either we have to lock the user account or return the standard message "invalid username or password" so that hacker should not be able to know whether at least username is correct if an hacker is trying with fake username.

What do you prefer guys either return the message of account lockout which may give indication to user that username is correct only password is incorrect or return the generic error message of "invalid user name or password" .

marked as duplicate by PwdRsch, Xander, kalina, Matthew, AndrolGenhald Apr 29 at 14:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1

We have implemented an account lockout functionality where we can lock the user attempts after configured number of attempts.

I cant help but wonder wont this result in denial of service?Why not try limiting password attempts by a specific system.But still at the end of the day you can only frustrate an attacker in an attack like bruteforce.

What do you prefer guys either return the message of account lockout which may give indication to user that username is correct only password is incorrect or return the generic error message of "invalid user name or password"

Its always told to only show a generic "wrong username or password" error message so that the attacker cannot better their brute force in anyway.

If the application is security sensitive.Add 2 factor authentication or use key based authentication

0

You don't need to reply with the information on account lockout no matter how many wrong attempts there are. You can explain the situation after the locked out user tries to log in with the correct password, and possibly require another factor due to the incident.

The purpose of  "invalid user name or password" is not to protect a single account against brute force, but the system against username enumeration. The alternative approach makes it too simple to try and lock out more users on the system.

  • If the attacker is notified that the account is locked out once he/she has guessed the correct credentials, what has the lockout really accomplished? The attacker still knows what the correct credentials are, and even if the user is forced to change his or her password after the lockout, there is a high likelyhood that the user will use a similar password. – Dan Landberg Apr 25 at 17:51
0

You may find this question helpful: Is it safe to show user a message if account is locked?

I would try to develop your threat model. Where could your attacker come from? Is this application only available inside your organization? Or is it public facing on the web? Lockouts are manageable when there's a relatively small number of people with access, but if anyone in the world can access it, an attacker could abuse this to lock out all your users.

If you want to lock accounts, I agree with Esa's answer that you should not alert the user of the lock until they successfully authenticate. While this means an attacker would know the password, they cannot access the application. If you fear this would still compromise the user, I think your best bet would be to implement some form of multi-factor authentication. (The only other alternative is never informing the user and thus requiring them to "give up" and reset their password on their own accord. I think this would be incredibly frustrating and would not recommend it)

If possible, block the client instead. A user who is making many failed attempts is likely malicious. Be aware this will not stop a distributed attack, though.

  • 1
    Hi Kevin, Yes, this application is only available inside the organization and not public facing on web. One more thing I would also like to mention is that currently we only do the auditing of such attempts means we don't insert such users in DB to manage their lock attempts for the prevention of DDos attack. Actually on Windows platform the native OS library does not give any specific status of non-exist user so there is difficult to identify whether it is invalid credential attempt of fake user attempt. So that's why we have to do account lock on Windows but they also want same for *ix. – anon Apr 25 at 18:26