fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Javier David <jda...@mifos.org>
Subject Re: [jira] [Created] (FINERACT-136) Security improvements on authentication/passwords
Date Mon, 11 Apr 2016 15:50:11 GMT
Hi Binny,

it's great to hear back from you!

You're absolutely right, point 2 is the same as the original point B.

With regards to point 1, I understand, and the developers will of course
make the final decision.

I find that it's potentially a strong tool against brute force, because it
increases the resources required on the attackers end and (depending on
certain implementation details) doesn't really increase them on your side.

The risk here is, if I'm not mistaken, that if you don't use some sort of
asynchronous model this can end up becoming a trivial DOS scenario (along
the lines of a "slow and low"-type attack, because it would keep your
threads occupied).

Also, if you go to the database to verify logins and/or store failed
attempts on the database the attacker can potentially bring your DB down
quite easily. Integration with an infrastructure-level firewall would
probably help with these issues (automated temporary IP banning at the
infrastructure level, or maybe even with iptables: your network adapter
could still be flooded, but at least your web server should be able to
function. And it's a different type of attack to a brute-force.).

An alternative to point 1 could be a captcha after a certain number of
failed attempts.

Point 5 - salt is important in case someone manages to steal your password
store. It protects against rainbow tables (precomputed hashes for
reverse-lookup).

I'll try to find out about writing to JIRA.

Thanks! Cheers!

JD.

On Mon, Apr 11, 2016 at 7:30 AM, Binny Gopinath Sreevas <
binny.gopinath@gmail.com> wrote:

> 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 <jdavid@mifos.org> 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)" <jira@apache.org
> >
> > 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)
> > >
> >
>



-- 
Javier David <jdavid@mifos.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message