Multiple Failed login attempts records in audit log

I generated this report from a customised audit logs report. ID 10501

In our system login screen, we have set the maximum failed login attempts limit to 5. However, the audit log report shows over 20 failed login attempts for this user. Does anybody have any idea about this?

-----------------------------------------------------------------------------------

********************Summary Information********************

Failed to set User XXX as Database User


***********************Event Details:**********************

Audit data guid: tM8lcjXW7KHJFH5/tS0Gug
Transaction id: 1012730828
Transaction sequence:
Audit date / time: 08/30/2024 10:35:43 AM
Event Name: _pvm.setdbuser.fail
Event Type: User
Database guid: 9FWv0QxHBJoURcl+Iq9mQA
Database description: corpdata
Database connection id: tM8lcjXW7KHJFA5+VAVj3g
Client session uuid: tM8lcjXW7KHJFH5/HDsRig
Audit Data Security Level: No Additional Security
Data Seal Generated:

------------------------------------------------------------------------------------

********************Summary Information********************

Failed to set User XXX as Database User


***********************Event Details:**********************

Audit data guid: tM8lcjXW7KHJFH5/0F3FuA
Transaction id: 1012730819
Transaction sequence:
Audit date / time: 08/30/2024 10:35:43 AM
Event Name: _pvm.setdbuser.fail
Event Type: User
Database guid: 9FWv0QxHBJoURcl+Iq9mQA
Database description: corpdata
Database connection id: tM8lcjXW7KHJFA5+VAVj3g
Client session uuid: tM8lcjXW7KHJFH5/HDsRig
Audit Data Security Level: No Additional Security
Data Seal Generated:

------------------------------------------------------------------------------------

After you fail 5 times you are “locked out”, right? Meaning that even if someone continues guessing (another 15 times) and happens to guess correctly they still don’t get in. But the attempts are noted. Which you would want.

TomBascom said:

After you fail 5 times you are “locked out”, right? Meaning that even if someone continues guessing (another 15 times) and happens to guess correctly they still don’t get in. But the attempts are noted. Which you would want.

Click to expand...

After you fail 5 times you are “locked out”, right? - yes
Yes, user logins are handled by the application level well, but the issue is, our internal auditors are requesting a "failed login attempts" report from the DB auditing. When i got the report, I noticed more than 30 logs for the same user in the report, and between log entries, there are no time gaps. As per this example,

Audit date / time: 08/30/2024 10:35:43 AM
Audit date / time: 08/30/2024 10:35:43 AM

So are auditors asking for an explanation for this?

Locking someone out after failed login attempts does not prevent additional *attempts*.

To do that you would need to teleport to the perpetrators location and handcuff them before than can start to try to login again.

Of course there could also be a gang of people trying to sneak in from multiple locations so you might also need telepathic powers to identify all of those people before they start on their next attempt. Which could be milliseconds from now.

Or it could be a scripted attack. Being run in parallel. From multiple locations.

Maybe your application tries to stop them by showing a scary warning message. But scary messages are easily ignored. If the user (or script) even bothers to read them.

One person failing 5 times does not disable login prompts. And the login prompt cannot know that a person is about to type in the userid of a user that is currently “locked out” because it does not know what id is being used until it is entered. Please forgive the idiom but it is a “chicken and the egg” situation.

I see absolutely nothing to “explain”. The report is showing exactly what it should. The person failing to login continued to fail and a record was made of those continued failures.

What would be disturbing, and in need of explanation, would be if on attempt #6 the user remembered their password and was *successful*.

TomBascom said:

Locking someone out after failed login attempts does not prevent additional *attempts*.

To do that you would need to teleport to the perpetrators location and handcuff them before than can start to try to login again.

Of course there could also be a gang of people trying to sneak in from multiple locations so you might also need telepathic powers to identify all of those people before they start on their next attempt. Which could be milliseconds from now.

Or it could be a scripted attack. Being run in parallel. From multiple locations.

Maybe your application tries to stop them by showing a scary warning message. But scary messages are easily ignored. If the user (or script) even bothers to read them.

One person failing 5 times does not disable login prompts. And the login prompt cannot know that a person is about to type in the userid of a user that is currently “locked out” because it does not know what id is being used until it is entered. Please forgive the idiom but it is a “chicken and the egg” situation.

I see absolutely nothing to “explain”. The report is showing exactly what it should. The person failing to login continued to fail and a record was made of those continued failures.

What would be disturbing, and in need of explanation, would be if on attempt #6 the user remembered their password and was *successful*.

Click to expand...

I have edited my previous reply because I have not explained my question properly. Sorry for the inconvenience. I wanted to highlight this part: "I noticed more than 30 logs for the same user in the report, and between log entries, there are no time gaps."

I've got no idea at all about your application, but that sounds like it's a scripted brute force event to me. And it looks like your application did what it was meant to.

Your report timestamp precision is only to the second. I don’t know if that is because the data captured is only precise to the second or if it is just being truncated. But if the underlying data is a datetime field you could get millisecond precision and would likely see some sort of “gaps”.

None the less, a large number of rapidly paced attempts is likely a scripted attack. (Or a bug in your login process.)

Along with increasing the precision of the timestamp you might like to try to capture more information about attempted logins. Source IP address and/or local device name for example. Maybe also the 4gl call stack that led to the login failure.