Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0038651
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminorhave not tried2018-05-29 16:142018-06-04 09:48
ReporteralostaleView Statuspublic 
Assigned Toalostale 
PrioritynormalResolutionfixedFixed in Version3.0PR18Q3
StatusclosedFix in branchFixed in SCM revisione32f0aa03825
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tocaristu
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0038651: problems in user locking implementation

DescriptionDelayed login after failed attempt and locking user functionalities have some minor issues:

1. When defining an incremental delay for login, it is only possible to set ranges of integer seconds. Increment by 1 second on each failed attempt is too much: it should be possible to define this increment to something smaller than complete seconds.
2. After a failed login attempt, login response is delayed. While in this delay, a database connection is kept open. It would be better to return it to the pool and get another one afterwards.
3. When trying to log in with a non existing user, delay is also correctly applied. The query count number of failed attempts is checking from the beginning of the time (incorrect HQL clause s.creationDate > s.creationDate-1 [1]. It should check if there was any attempt during the last one day at most.
4. After a user is locked, subsequent login attempts mark it as locked again

---
[1] https://code.openbravo.com/erp/devel/pi/file/3.0PR18Q2/src/org/openbravo/base/secureApp/UserLock.java#l119 [^]
Steps To Reproduce1.1 Configure login.trial.delay.increment to something smaller than a second ie (0.5 secs).
1.2 Start tomcat and try to login
  -> An exception is logged and no delay is applied

2.1 Configure to several seconds delay
2.2 Fail login
   -> check an idle in transaction connection is kept open while delaying response

3.1 create 60 entries in ad_session for an invalid user (ie. uername='xx') with creation date 1 month ago
3.2 configure to increment delay 1 second up to 60 seconds
3.3 try to login with user xx
   -> request is delayed 60 seconds

4.1 configure to lock user after 2 failed login attempts
4.2 try to login with a valid user and an incorrect password 2 times
  -> WARN message is displayed in openbravo.log -> OK
4.3 do the same again
  -> the same message appears in log -> Incorrect, once the user is locked it should not be locked again until unlocked.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 00254663.0PR14Q2 closedalostale Performace problem during the login 
related to defect 0038655 closedalostale incorrect query in UserLock 
blocks feature request 0038652 closedalostale security default: delay response after failed login attempt 

-  Notes
(0104776)
hgbot (developer)
2018-05-29 16:19

 Repository: erp/devel/pi
Changeset: e32f0aa03825361dbae92f10c849f9772751209a
Author: Asier Lostalé <asier.lostale <at> openbravo.com>
Date: Tue May 29 16:18:01 2018 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/e32f0aa03825361dbae92f10c849f9772751209a [^]

fixes 38651: problems in user locking implementation

  Fixes some problems in user locking:

    1. When defining an incremental delay for login, it is only possible to set
       ranges of integer seconds. Increment by 1 second on each failed attempt
       is too much: it should be possible to define this increment to something
       smaller than complete seconds.
    2. After a failed login attempt, login response is delayed. While in this
       delay, a database connection is kept open. It would be better to return
       it to the pool and get another one afterwards.
    3. When trying to log in with a non existing user, delay is also correctly
       applied. The query count number of failed attempts is checking from the
       beginning of the time. It should check if there was any attempt during the
       last one day at most.
    4. After a user is locked, subsequent login attempts mark it as locked again.

---
M src/org/openbravo/base/secureApp/LoginUtils.java
M src/org/openbravo/base/secureApp/UserLock.java
---
(0104903)
caristu (developer)
2018-06-04 09:48

 Code reviewed + tested OK.

- Issue History
Date Modified Username Field Change
2018-05-29 16:14 alostale New Issue
2018-05-29 16:14 alostale Assigned To => alostale
2018-05-29 16:14 alostale Modules => Core
2018-05-29 16:14 alostale Triggers an Emergency Pack => No
2018-05-29 16:18 alostale Relationship added related to 0025466
2018-05-29 16:18 alostale Review Assigned To => caristu
2018-05-29 16:19 hgbot Checkin
2018-05-29 16:19 hgbot Note Added: 0104776
2018-05-29 16:19 hgbot Status new => resolved
2018-05-29 16:19 hgbot Resolution open => fixed
2018-05-29 16:19 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/e32f0aa03825361dbae92f10c849f9772751209a [^]
2018-05-29 16:31 alostale Relationship added blocks 0038652
2018-05-30 10:27 alostale Relationship added related to 0038655
2018-06-04 09:48 caristu Note Added: 0104903
2018-06-04 09:48 caristu Status resolved => closed
2018-06-04 09:48 caristu Fixed in Version => 3.0PR18Q3

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker