Trusted devices
For Meddbase user logins, there is a concept of a ‘trusted’ device. A trusted device is a browser where a specific user has successfully logged in before. This is implemented using a signed ‘JWT’ cookie that is specific to one username.
We use the ‘trusted device’ status of a login attempt to tailor our response to attacks, detailed below.
Failed login tracking for specific usernames
When a failed login attempt is made for a particular username, meddbase keeps two tallies for that username. One tally is for attempts from a trusted device. The other tally is for attempts from untrusted devices.
For trusted logins, once the warning threshold is reached (currently 10 tallies), that specific trust cookie is considered to be potentially compromised and will no longer be trusted.
In either case, once the warning threshold is reached, the username is considered to be ‘under attack’. This status can only be reset by a Meddbase support user, or a successful login. While a username is ‘under attack’ any login attempt for that username from an untrusted device (success or failure) will take 10 minutes to complete.
Note that logins from trusted devices are never delayed.
Global failed login tracking
Independently from the username tallies, meddbase also keep a count of all failed logins within the last 10 minutes, per Meddbase instance. If the total number of failed logins in a 10 minute window exceeds a threshold (30 attempts) then the affected instance is considered to be under ‘global attack’ for the next 30 minutes. Only a Meddbase support user can reset the ‘global attack’ status.
The ‘global attack’ status has no effect on trusted logins.
During the ‘global attack’ all untrusted logins (success or failure) are delayed for 10 seconds.
If either tally reaches a second threshold (currently 50) then the license is removed for the affected user. This can be restored by a Meddbase support user, or a general Meddbase user with the appropriate permissions. The 10 minute delay between untrusted login attempts means that, in practise, it is very difficult for a careless user to reach this threshold.
Ways to resolve the issue.
You will have to contact customer support, with the request to unblock the specific user from the global attack list.
The next step is to ask a system administrator to re-assign the licence. (Refer to the article here for guidance on how to do this)
And lastly, reset the password of the user affected. (Refer to the article here for guidance on how to do this)