Comment # 14 on bug 1078111 from Nicolas �vrard

(In reply to Luis Falcon from comment #13)
> Dear Mathias, dear all
> 
> Let me re-enforce the fact that today we have a security problem, with an
> open and widely known vulnerability on the tryton server.
> 
> IMO, we should take a two-stage :
> 
> ** Stage 1 (present): Needs immediate action **
> 
> Mitigating _current_ vulnerability of flooding with anonymous writes the DB
> engine (see comment 3 for details
> https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c3)

I agree that this vulnerability should be better handled (and we do that there
has been patches limiting the behaviour you describe)
But if there was a simple way to do it, we wouldn't be talking about it right
now.

> A simple patch was written with the following functionality: 
> 
> a) Avoids anonymous writes to the DB, and
> b) Imposes a default 3-second penalty to any failed login attempt,
> mitigating also the brute-force attack. 
> 
> IMO, we take care of a) and b).
> 
> Mathias, to answer one of your question, it implements a simple, yet
> effective password brute-force protection in place without allowing
> anonymous writing on the DB. That said, I am positive it can be improved /
> optimized in upstream.

It will need to be improved since you're not waiting at all when the login is
successful.
A clever attacker will know that if its process waits 0.5 seconds then it's
probably not the right password, thus he can drop the connection and start with
another one.
Thus your patch must wait unconditionally 3 seconds. So even for successful
login attempt users will have to wait 3 seconds. 
This is a regression for people that know their password (which should
fortunately be the usual case).

That's why I still prefer the exponential wait way.

> This can be implemented in scenarios with multiple application servers and
> different operating systems. I know SAP, and SAP deals with with
> authentication, password quality control, auditing and logging with multiple
> application servers, allowing mixing operating systems in the same SID,
> without letting the DB being flooded by anonymous writes. A similar solution
> is feasible in Tryton too.

Could you please describe the solution SAP is using in the multiple application
server case?
I have some ideas about it but all the ideas I have are always involving other
systems complicating deployment, IPC calls or something.

About the use case, I know one company that is doing it. Maybe others are doing
it also (I think about semilimes) but they didn't share the details of their
infrastructure with us.

Storing the login attempts per machine is a subject of discussion, because then
(assuming they reply using a round-robin algorithm) you're dividing the waiting
time by the number of machine answering requests. On the other hand the
exponential will always grows faster then the linear function so it might be
seen as OK so I think we should discuss this further.

> What we can not, and will not accept is to leave the current system security
> compromised as it is today, just because a discussion on which brute force
> attack protection is better among two existing and _valid_ alternatives. So
> the patch will remain in place until we get a satisfactory solution from
> upstream.

I must say that you can do whatever you want in GNU Health. It's your project
you're free to apply all the patches you want.

Another solution would be to have two packages in openSUSE (I am used to debian
so I will use their terminology):

 - A virtual package trytond-server
 - Two packages:
    - GNU Health trytond: a package providing trytond-server with Luis' patch
    - Vanilla trytond: a package also providing trytond-server without Luis'
patch
 - Tryton modules should depend on trytond-server

This is a burden for Axel because he will have to create this the first time
but I guess that once it's done the process can be completely automated (IIRC
the talks you gave in Buenos Aires).

> In addition, and as a side note, we can not cover the sun with one finger.
> For example, I find contradictory rejecting a solution that mitigates a
> vulnerability because it uses a different -yet valid- approach to brute
> force protection, while allowing things such as 
> 
> "123456789" as a valid password in Tryton. This is ranked number 2 most used
> password
> (http://www.telegraph.co.uk/technology/2017/01/16/worlds-common-passwords-
> revealed-using/)

> I proposed using cracklib to harden passwords
> (https://bugs.tryton.org/msg24736) , but it was not taken. I must admit it
> gets a bit frustrating after proposing features / patches and not seeing
> them implemented. Luckily, this is Free Software, so we can apply them in
> GNU Health, when consensus with upstream is not reached.

I don't like rules on password and I was against the inclusion of the patches
to define rules on them (it's a bit more complicated than that as I was not
against everything but as you can see my ideas are not always taken into
account either).
There is plenty of litterature that explain why rules for passwords are bad.

Yet we have configuration options that allow to define the strength of the
password and by tweaking them you can prevent user to use simple passwords (one
of them allows to define a file with the list of unallowed passwords).

About your frustration, I can understand it. But again: bloating Tryton with
options is not in our design philosophy (another reason why I hated the
password rules), so having an option to activate PAM (because it does not work
on openbsd and windows and we value cross-platform support) was not in our
plan. I am sorry that it generated frustration but we also have our freedom to
decide what should go inside core tryton or not.

> ** Stage 2 ** 
> 
> Improving / hardening overall security in Tryton. 

Of course, I agree that we should discuss security issue and have open-minded
talks about the solutions. But I don't think this bug is the right place to do
so (and we already digress way too much).