Zur Boardunity Forenstartseite

Zurück   Boardunity & Video Forum » Software & Projekte » Forensoftware

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1  
Alt 30.12.2005, 18:00
Benutzerbild von Gérome
*wurgelpurgel*
 
Registriert seit: 08.2003
Ort: Server-Raum im Keller
Beiträge: 243

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*

  #2  
Alt 30.12.2005, 22:29
Mitglied
 
Registriert seit: 12.2005
Beiträge: 45
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.

  #3  
Alt 30.12.2005, 23:31
Benutzerbild von Gérome
*wurgelpurgel*
 
Registriert seit: 08.2003
Ort: Server-Raum im Keller
Beiträge: 243
ä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.

  #4  
Alt 31.12.2005, 01:49
Benutzerbild von Luki
Administrator
 
Registriert seit: 02.2004
Ort: Hamburg
Beiträge: 486
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!


Geändert von Luki (31.12.2005 um 11:29 Uhr).
  #5  
Alt 31.12.2005, 10:00
Benutzerbild von Gérome
*wurgelpurgel*
 
Registriert seit: 08.2003
Ort: Server-Raum im Keller
Beiträge: 243
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.

  #6  
Alt 31.12.2005, 11:10
Linuxfanatiker
 
Registriert seit: 10.2005
Ort: Innnsbruck
Beiträge: 166
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!

  #7  
Alt 01.01.2006, 11:32
Benutzerbild von Gérome
*wurgelpurgel*
 
Registriert seit: 08.2003
Ort: Server-Raum im Keller
Beiträge: 243
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.

  #8  
Alt 01.01.2006, 15:16
Benutzerbild von Luki
Administrator
 
Registriert seit: 02.2004
Ort: Hamburg
Beiträge: 486
tztz dann sollen die da bitte einen Captcha einbauen!!
aber die Lösung im Augenblick ist wirklich traurig!

  #9  
Alt 02.01.2006, 09:30
Benutzerbild von MaMo
Viscacha Coder
 
Registriert seit: 09.2003
Beiträge: 812
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.

__________________
Forensoftware mit integriertem CMS: Viscacha 0.8!
  #10  
Alt 02.01.2006, 12:24
Benutzerbild von Luki
Administrator
 
Registriert seit: 02.2004
Ort: Hamburg
Beiträge: 486
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!)

Antwort


Stichworte
-


Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
phpBB oder SMF? Windwalker Forensoftware 34 21.08.2008 03:03
Das phpBB 2 Daniel Richter Erfahrungsberichte 57 21.04.2006 21:12
phpBB Community Coding Projekte itst Forensoftware 12 25.11.2005 15:01
phpBB Planet Planet Projektvorstellung und Bewertung 5 04.09.2005 22:26






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