Is there a limit to the number of wrong password entries during log in?

majbador

Hi! Does the log in have a limit to the number of wrong password entries? If a user has entered wrong password for an x number of times, what happens to the account?

Would appreciate some information on this. Thanks!

Hari

majbador as far I know there is no extension that enables this functionality but however it is possible to build an extension to fulfil the need.

Walys

majbador
Good point. In other systems when you have error password three times need to await some minutes to retrieve.

majbador

@Hari @Walys yeah, having a limit to wrong password entries could also be a security feature, esp. against those who are trying to hack another user's account.

Valeyard

majbador yeah, having a limit to wrong password entries could also be a security feature, esp. against those who are trying to hack another user's account.

I would like to get password security up to most of NIST's standards (described here) potentially with my own extension which isn't that difficult really. There are really good extensions you can install in the meantime to increase password security:

With Passwordless login I recommend changing the default text which will require the use of FoF Linguist. I use Discourse's text basically which is "Skip the password login via email instead" and "Login with password". Using it in this way allows members who have temporarily forgotten their password to get a login link without having to set a brand-new password.

I would also recommend changing the default text of Pwned Passwords as well since you want to reassure your users when they receive that warning or error (which WILL happen) that their password has not been shared. Most people will wrongly assume that to check their password against a breached password list it has to be shared somehow, but that's not how it works - it's done on the client's device and you can read about how it works here.

CyberGene

There shouldn’t be a limit to the number of attempts because someone may maliciously block your account this way. A better way is to introduce delays on subsequent attempts, so that brute forcing becomes impractical.

Valeyard

CyberGene You don't block the account, you block the IP address.

Yes delays are the preferred way to limit login attempts, such as by requiring hCapture after 10 failed attempts or something like that.

RelicSystem

Valeyard You don't block the account, you block the IP address.

proxy, vpn, ssh tunnel etc and you bypass the block - better to lock down the account attempted to be brute forced and notify the owner of the account.

Valeyard

RelicSystem Where are you getting that idea?

NIST Special Publication 800-63-3

4.3.3 Authentication Process

The authentication process begins with the claimant demonstrating to the verifier possession and control of an authenticator that is bound to the asserted identity through an authentication protocol. Once possession and control have been demonstrated, the verifier verifies that the credential remains valid, usually by interacting with the CSP.

The exact nature of the interaction between the verifier and the claimant during the authentication protocol is extremely important in determining the overall security of the system. Well-designed protocols can protect the integrity and confidentiality of communication between the claimant and the verifier both during and after the authentication, and can help limit the damage that can be done by an attacker masquerading as a legitimate verifier.

Additionally, mechanisms located at the verifier can mitigate online guessing attacks against lower entropy secrets — like passwords and PINs — by limiting the rate at which an attacker can make authentication attempts, or otherwise delaying incorrect attempts. Generally, this is done by keeping track of and limiting the number of unsuccessful attempts, since the premise of an online guessing attack is that most attempts will fail.

The verifier is a functional role, but is frequently implemented in combination with the CSP, the RP, or both. If the verifier is a separate entity from the CSP, it is often desirable to ensure that the verifier does not learn the subscriber’s authenticator secret in the process of authentication, or at least to ensure that the verifier does not have unrestricted access to secrets stored by the CSP.

Rate limiting is the recommended way to mitigate the threat of brute-force, not account locking. It specifically says rate limiting the potential attacker, not the account. If you locked the account after a brute-force attack then an attacker could target administrator usernames and get them locked-out of their forum and unable to login.

RelicSystem

Valeyard you have an idea of what you feel is best and per your post you plan to write a plug-in to make that happen so best of luck to you 😄

Hari

3 wrong attempts to ban IP or user for 15min, 30min ..etc would be a good approach.

Valeyard

Hari No it wouldn't! That would lead to a terrible user experience. If someone is using a secure password it can take multiple attempts to get it right - I know this first-hand. You do not want to punish that.

Hari

Valeyard I thought it is the easiest way, in my country all banks do this for net-banking 😋

in my case, I limited my website to social login only, so I need not worry about this. 😉

Valeyard

Guys, I don't have "an idea of what I feel is right". I know the previous NIST guidelines were deficient. I'm not that simple give me some credit!

Yes I plan to write a plugin to increase login securely. Operative word there being plan. I give no guarantee, unless someone wants to commission the work.

RelicSystem

Valeyard Guys, I don't have "an idea of what I feel is right". I know the previous NIST guidelines were deficient. I'm not that simple give me some credit!

No Malice intended at all more a you do you thing 🙂

murdocklawless

if flarum writes wrong password entries to the log, it can be easily limited with fail2ban.