Boardunity & Video Forum

Boardunity & Video Forum (https://boardunity.de/)
-   Forensoftware (https://boardunity.de/forensoftware-f5.html)
-   -   phpBB 2.0.19 ist fertig (https://boardunity.de/phpbb-2-0-19-fertig-t3847.html)

Gérome 30.12.2005 17:00

phpBB 2.0.19 ist fertig
 
Seit in paar Stunden ist die Version von phpBB 2.0.19 erhältlich. Neu ist eine optionale Begrenzung der fehlerhaften Login-Versuche. Daneben gibt es eine reihe an Bugfixes - sei es für die Unterstützung von mySQL 5 oder aber ein paar sicherheitskritischer Lücken, die in speziellen Konfigurationen ausgenutzt worden sind.

Die Ankündigung ist zu finden unter:
http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=352966

Ich muss da jetzt irgendwie an Loriot denken: Ein Klavier, ein Klavier! *grins*

dominik 30.12.2005 21:29

Ich warte noch mit dem Update, dieses neue "Login-Schutz-Feature" ist anscheinend sehr zweifelhaft. Auf phpbb.de wird fleissig darüber diskutiert, mal schaun was dabei raus kommt.

Gérome 30.12.2005 22:31

ähm ... ja. Wenn es tatsächlich so ist, dass dieses System auf Account-Ebene und nicht auf IP-Ebene arbeitet, dann ist die Implementation nicht das Gelbe vom Ei. Wohl wahr.

Luki 31.12.2005 00:49

LOL, wenn die das auf Account Ebene gemacht habe, verliere ich das Vertrauen ins PHPBB!!
ich setze dann mal ein Login Autoscript auf "alle Accounts" :)

solche Kardinalfehler sprechen echt gegen ein gutes Developer Team!

Gérome 31.12.2005 09:00

Um das phpBB nicht zu Unrecht zu kritisieren, habe ich mir die Codestellen eben angesehen:


Code:

  // If the last login is more than x minutes ago, then reset the login tries/time
    if ($row['user_last_login_try'] && $board_config['login_reset_time'] && $row['user_last_login_try'] < (time() - ($board_config['login_reset_time'] * 60)))
    {
    $db->sql_query('UPDATE ' . USERS_TABLE . ' SET user_login_tries = 0, user_last_login_try = 0 WHERE user_id = ' . $row['user_id']);
    $row['user_last_login_try'] = $row['user_login_tries'] = 0;
    }
 
    // Check to see if user is allowed to login again... if his tries are exceeded
    if ($row['user_last_login_try'] && $board_config['login_reset_time'] && $board_config['max_login_attempts'] &&
    $row['user_last_login_try'] >= (time() - ($board_config['login_reset_time'] * 60)) && $row['user_login_tries'] >= $board_config['max_login_attempts'])
    {
    message_die(GENERAL_MESSAGE, sprintf($lang['Login_attempts_exceeded'], $board_config['max_login_attempts'], $board_config['login_reset_time']));
    }


Ja, das Ganze läuft auf Account-Ebene und ist damit in meinen Augen sehr kontraproduktiv. Das Risiko, dass Dritte diesen Counter an seine Grenzen treiben und damit den regulären Benutzern den Weg ins Forum versperren, ist einfach zu groß. Per Standard hat ein Benutzer 5 Versuche, sich einzuloggen. Ich sende also 5 HTTP-Posts ab (brauche dazu weniger als eine Sekunde) und User X kann sich für 30 Minuten (Standard-Vorgabe) nicht einloggen. Das mache ich schnell für alle Team-Mitglieder und hab' als Troll 'ne Weile Ruhe im Board.

Es ist mir unbegreiflich, wie das phpBB-Team zu solch einer Entscheidung kommen konnte. Das sind alles gestandene Web-Entwickler mit jahrelanger Erfahrung in diesem Gebiet.

michi50 31.12.2005 10:10

Zitat:

Zitat von Gérome
Um das phpBB nicht zu Unrecht zu kritisieren, habe ich mir die Codestellen eben angesehen:


Code:

  // If the last login is more than x minutes ago, then reset the login tries/time
    if ($row['user_last_login_try'] && $board_config['login_reset_time'] && $row['user_last_login_try'] < (time() - ($board_config['login_reset_time'] * 60)))
    {
    $db->sql_query('UPDATE ' . USERS_TABLE . ' SET user_login_tries = 0, user_last_login_try = 0 WHERE user_id = ' . $row['user_id']);
    $row['user_last_login_try'] = $row['user_login_tries'] = 0;
    }
 
    // Check to see if user is allowed to login again... if his tries are exceeded
    if ($row['user_last_login_try'] && $board_config['login_reset_time'] && $board_config['max_login_attempts'] &&
    $row['user_last_login_try'] >= (time() - ($board_config['login_reset_time'] * 60)) && $row['user_login_tries'] >= $board_config['max_login_attempts'])
    {
    message_die(GENERAL_MESSAGE, sprintf($lang['Login_attempts_exceeded'], $board_config['max_login_attempts'], $board_config['login_reset_time']));
    }

Ja, das Ganze läuft auf Account-Ebene und ist damit in meinen Augen sehr kontraproduktiv. Das Risiko, dass Dritte diesen Counter an seine Grenzen treiben und damit den regulären Benutzern den Weg ins Forum versperren, ist einfach zu groß. Per Standard hat ein Benutzer 5 Versuche, sich einzuloggen. Ich sende also 5 HTTP-Posts ab (brauche dazu weniger als eine Sekunde) und User X kann sich für 30 Minuten (Standard-Vorgabe) nicht einloggen. Das mache ich schnell für alle Team-Mitglieder und hab' als Troll 'ne Weile Ruhe im Board.

Es ist mir unbegreiflich, wie das phpBB-Team zu solch einer Entscheidung kommen konnte. Das sind alles gestandene Web-Entwickler mit jahrelanger Erfahrung in diesem Gebiet.

Ist ja gut das ein ein neues Feature gibt und nicht nur ein par fixes.
Aber wenn man es so leicht manipulieren kann ist es einfach nichts!
Ich hab schon das update gemacht!

Gérome 01.01.2006 10:32

Zitat:

Zitat von Gérome
Es ist mir unbegreiflich, wie das phpBB-Team zu solch einer Entscheidung kommen konnte. Das sind alles gestandene Web-Entwickler mit jahrelanger Erfahrung in diesem Gebiet.

Nun, diese Frage wurde beantwortet:

Zitat:

Rotating proxies is the main reason for why it was done this way. AOL users can find their IP address changing constantly. We have had problems in the past because of rotating proxies.
Man mag unterschiedlicher Ansicht über diese Antwort sein.

Luki 01.01.2006 14:16

tztz dann sollen die da bitte einen Captcha einbauen!! :)
aber die Lösung im Augenblick ist wirklich traurig!

MaMo 02.01.2006 08:30

Zitat:

Zitat von Gérome
Rotating proxies is the main reason for why it was done this way. AOL users can find their IP address changing constantly. We have had problems in the past because of rotating proxies.

Korrigiert mich, aber dann kann man es immer noch auf Ebenen-Basis machen. Nimmt man halt anstelle 11.22.33.44 sowas: 11.22.33. und prüft auf den Bereich, sollte auf jeden Fall weniger anfällig sein.

Luki 02.01.2006 11:24

naja soweit ich das sehe, geht es hier ja nur darum, automatisierte Bruteforce Einlogg-Versuche zu verhindern...

also sollte man dem Useraccount bei zu vielen Fehl-Logins einfach eine zusätzliche Captcha Eingabe verpassen. (wäre natürlich eleganter als eine IP Sperre!)


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:13 Uhr.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25