Hi Javier, Sorry for delayed response.
Point 2 will be implemented by by point b) in the JIRA, correct? Agree with points 3 and 4. You could add these as comments on the JIRA or edit the JIRA itself. For point 1 - I will leave it to one of the developers to comment if it is a good practice to induce such delays. For point 5 - my understanding it that it is a one-way hash. And we do not use any salt. One of the developers could comment on this. - Binny On Thu, Apr 7, 2016 at 9:51 PM, Javier David <[email protected]> wrote: > Hi! > > I apologize in advance for invading this thread, especially since I've > contributed no source code at all. I would like to recomend that, if we > improve this, a few additional tricks can also help in preventing brute > force: > > 1) increasing delay between "login failed" responses to succesive attempts > from the same IP. > > so the first time a login fails from a specific IP you sleep one second > then reply "login failed". the second time two seconds. the third time > three seconds. the fourth time after 5 or 10 seconds,you respond "IP > banned" and temporarily (10 minutes maybe?) and fail each additional login > attempt from that IP after a 10 second wait with an "IP banned" message > until you have 10 minutes (or whatever time span is appropriate) with no > failed login attempts from that IP. > > 2) if the same user fails three successive login attempts, block his > account until manual intervention occurs, but don't report this to the > user. > > 3) ensure that the system, while logging a different error on the server, > gives the same response to the client for an invalid login, whether the > user exists or not (i.e. never set a different code or respond in any way > differently for inexistant o unauthorized user than for wrong password or > wrong 2fa code. always answer "invalid login", or some such neutral reply) > > 4) if we don't have it already, add the possibility of 2FA. I recomend > google autheniticator. it's open source, and has clients for android and > ios. > > 5) against another type of brute force, I'm assuming we store the passwords > using some strong crypto one-way hash with few colisions and salt it with > variable data? > > hope this helps and once again, sorry for "invading" this thread... > > > On Apr 7, 2016 6:04 AM, "Binny Gopinath Sreevas (JIRA)" <[email protected]> > wrote: > > > Binny Gopinath Sreevas created FINERACT-136: > > ----------------------------------------------- > > > > Summary: Security improvements on authentication/passwords > > Key: FINERACT-136 > > URL: https://issues.apache.org/jira/browse/FINERACT-136 > > Project: Apache Fineract > > Issue Type: Improvement > > Reporter: Binny Gopinath Sreevas > > Assignee: Markus Geiss > > > > > > Make improvements to keep track of authentication attempts and security > by > > doing the following: > > a) Logging user logins - whenever any user tries to login (success or > > failure) below logs should be stored in the database: > > username/userid > > user agent (Browser, OS, device) > > IP address > > Date/Time > > login success or failure > > > > b) Facility to preventing brute force attacking - system should block the > > user after n unsuccessful attempts in a day for m number of days, (n,m > are > > configurable) > > > > c) Configure passwords to expire - for example: after 2 months - Should > be > > possible to set non-expiring passwords as a policy for the organization. > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.3.4#6332) > > >
