Project

General

Profile

Actions

Feature #1530

closed

Task #1503: Testing of the product (9.4.0)

Login block (2nd in a row) behaves differently after the elapse of 1st block

Added by milus kotisova almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Ondřej Kopr
Category:
Password policy
Target version:
Start date:
02/21/2019
Due date:
% Done:

100%

Estimated time:
Owner:

Description

TC 97 (scenario b) Password: blocking a user after x failed login attempts

@affected version 9.4.0

The same rule (say, maximum 2 failed attempts) should apply again and again, once a previous blocking time has elapsed, starting from scratch, allowing the user to enter 2 wrong passwords each time.

The test case was that the first blocking period has elapsed. After an elapse of that period, I logged in unsuccessfully just once more, but my second only attempt was using the correct password, but I was blocked right after the first attempt this time. Which is unexpected, given the set policy.

The user should not be stopped indefinitely from entering wrong passwords but instead get a new chance of entering 2 or x wrong passwords each time a blocking period has elapsed.

Actions #1

Updated by Alena Peterová almost 6 years ago

  • Target version set to Quartz (9.6.0)
Actions #3

Updated by Vít Švanda almost 6 years ago

  • Tracker changed from Defect to Feature
Actions #4

Updated by Alena Peterová almost 6 years ago

Well, I really hope that my online banking doesn't consider this behavior to be a feature. ;-)

In Windows (Active Directory), the user has the same number of attempts repeatedly (https://blogs.technet.microsoft.com/secguide/2014/08/13/configuring-account-lockout/, https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after)

Actions #5

Updated by Ondřej Kopr almost 6 years ago

  • Status changed from New to In Progress
Actions #6

Updated by Ondřej Kopr almost 6 years ago

This feature will be little bit upgraded:

new behavior: after user reached max unsuccessful attempts will be blocked for seconds that is defined in password policy. After blocking date expires and user still try login and failed. New date block will be multiplied by 2. After next attemps will be multiplied by 3, and .... To user will be sent message directly to gui with information about block login.

original behavior: when user reached max unsuccessful attempts during seconds that is defined in password policy, the user will be blocked with message in gui.

Actions #7

Updated by Marcel Poul almost 6 years ago

Ondřej Kopr wrote:

This feature will be little bit upgraded:

new behavior: after user reached max unsuccessful attempts will be blocked for seconds that is defined in password policy. After blocking date expires and user still try login and failed. New date block will be multiplied by 2. After next attemps will be multiplied by 3, and .... To user will be sent message directly to gui with information about block login

From my point of view, this really is overkill. Blocking period is fine to prevent brute force attacks. These types of attacks are based on huge amount of attempts in short period of time (ms) and any delay that is in higher order ( tens of seconds or even minutes) is good enough. If this is not enought, then the password policy itself is really bad.

Expected behaviour by me is just telling the user "limit reached, wait 5minutes" and wait. Then reset the counter.

Actions #9

Updated by Ondřej Kopr almost 6 years ago

  • % Done changed from 0 to 10
Actions #10

Updated by Ondřej Kopr almost 6 years ago

  • Status changed from In Progress to Needs feedback
  • % Done changed from 10 to 90

The whole feature was done. Works as describes commentaries.

Commi: https://github.com/bcvsolutions/CzechIdMng/commit/c85b6efae91589d31d8cfe420e4c989fe657c59e (branch develop)
Documentaion: https://wiki.czechidm.com/devel/documentation/security/dev/password-policies#standard_policy_for_validation

Please Vitek could you check the new behavior? Thank you

Actions #11

Updated by Ondřej Kopr over 5 years ago

  • Assignee changed from Ondřej Kopr to Vít Švanda
Actions #12

Updated by Vít Švanda over 5 years ago

  • Status changed from Needs feedback to Resolved
  • Assignee changed from Vít Švanda to Ondřej Kopr
  • % Done changed from 90 to 100

I tested it. Now it is more UX. Thanks for that.

Actions #13

Updated by Ondřej Kopr over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF