delay() oder SetTimeOut() in PHP?

[Stefan Billewicz]

Hallo,
existiert eigentlich in PHP (4) eine Funktion, die einfach nur wartet, wie z.B. "delay()" in TurboPascal/Delphi oder "SetTimeOut()" in JavaScript?

Wenn nicht, so würde mir eigentlich nur folgende Variante einfallen:

--------------------------
$x=time();
while(($y-$x) < 10000)
{
  $y=time();
}
--------------------------

Ich könnte mir allerdings vorstellen, dass so eine Variante doch recht belastent für den ausführenden Server sein könnte, dafür dass eigentlich gar nichts passieren soll. Stimmt dass?
Oder läuft ein "SetTimeout" intern nach dem gleichen Prinzip ab?

Wär nett wenn mir jemand helfen würde..
mfg
Stefan

[Christian Seiler]

Hallo Stefan,

existiert eigentlich in PHP (4) eine Funktion, die einfach nur wartet, wie z.B. "delay()" in TurboPascal/Delphi oder "SetTimeOut()" in JavaScript?

Jain. Analog zu delay() ja, analog zu setTimeout nicht. Nach dem Aufruf von setTimeout läuft der Javascript-Code ja weiter, nur wird die angegebene Funktion nach dieser Zeit halt aufgerufen. Bei delay() in Pascal wird ja die Zeit gewartet, bevor die Funktion zurückkehrt.

Unter PHP heißt die Funktion sleep: http://de3.php.net/de/sleep Allerdings habe ich diese Funktion bei Webanwendungen bisher nie gebraucht.

Viele Grüße,
Christian

[Stefan Billewicz]

Hallo Christian,
danke für deine Antwort.

Unter PHP heißt die Funktion sleep:

Danke. Komisch, dass ich noch selbst nie auf diese Fkt. gestoßen bin.

»»Allerdings habe ich diese Funktion bei Webanwendungen bisher nie gebraucht.

Ich habe einen eine Seite programmiert auf der man sich in echtzeit unterhalten kann. Einen kleinen Chat sozusagen.
Dabei lassse ich alle paar sekunden prüfen, ob jemand einen neuen Beitrag geschrieben hat. Wenn ja wird er ausgegeben.

Das habe ich bisher mit SetTimeOut und reload kontrolliert.
Würde es aber lieber komplett in PHP machen (-->sleep).

Oder ist dieses Konzept eines Chats komplett abwegig?
Bin ja sicher nicht der erste, der sowas selbst programmiert. Vielleicht kannst du (oder jemand anders) einen kleinen Hinweis geben, falls es anders wesentlich besser geht.

mfg
Stefan

[Cheatah]

Hi,

Oder ist dieses Konzept eines Chats komplett abwegig?

das Konzept, einen Chat über HTTP realisieren zu wollen, ist absurd. Das ist als würdest Du ein Flugzeug bauen, welches die Autobahnen verwenden soll.

Bin ja sicher nicht der erste, der sowas selbst programmiert.

Nein. Deswegen findest Du die Gründe für die Absurdität auch im </archiv/>. Stichworte sind z.B. "zustandslos" und "verbindungslos" - beides sind für einen Chat benötigte und in HTTP nicht vorhandene Faktoren.

Cheatah

[Yeti]

Hi,

Ich habe einen eine Seite programmiert auf der man sich in echtzeit unterhalten kann. Einen kleinen Chat sozusagen.
Dabei lassse ich alle paar sekunden prüfen, ob jemand einen neuen Beitrag geschrieben hat. Wenn ja wird er ausgegeben.

Das habe ich bisher mit SetTimeOut und reload kontrolliert.
Würde es aber lieber komplett in PHP machen (-->sleep).

Oder ist dieses Konzept eines Chats komplett abwegig?
Bin ja sicher nicht der erste, der sowas selbst programmiert. Vielleicht kannst du (oder jemand anders) einen kleinen Hinweis geben, falls es anders wesentlich besser geht.

Use IRC for chat! :-)
Komplett abwegig ist es nicht. Es gab lange Zeit Webchat-Software, die darauf beruhte die Website nie komplett zu schicken sondern immer vorzugaukeln, es käme noch etwas und dann solange zu warten, bis ein anderer Chatter etwas geschrieben hat. Dann wurde das einfach angehängt.
Allerdings scheitert diese Methode hauptsächlich daran, dass der Internet Explorer nicht immer sofort alles darstellt, was er empfangen hat.

Wenn du _unbedingt_ einen Webchat brauchst, weil deine Besucher nicht auf www.mirc.com (o.ä.) kommen, dann benutze ein Java-Applet (igitt :-) ) als IRC-Gateway.

Der Yeti

[Cheatah]

Hi,

existiert eigentlich in PHP (4) eine Funktion, die einfach nur wartet,

was für einen Sinn hätte es, die Ausgabe an den Client zu verzögern? Der Benutzer würde vor einem leeren Browserfenster sitzen. Das widerspricht dem Sinn der Technik völlig.

Cheatah

[Yeti]

Hi,
eine der praktischsten Anwendungen: Die Ausgabe nach einem Loginvorgang um ca. 5 Sekunden verzögern, um eine Brute-Force-Attacke unrentabel zu machen.
Weitere denkbare Anwendungsmöglichkeiten:
1. Warten auf Prozesse, die im Hintergrund ablaufen
2. Dem Client einen Status anzeigen (z.B. jede Sekunde ein bestimmtes div dynamisch neu schreiben)
3. Warten auf Godot
Der Yeti

[Christian Seiler]

Hallo Yeti,

eine der praktischsten Anwendungen: Die Ausgabe nach einem Loginvorgang um ca. 5 Sekunden verzögern, um eine Brute-Force-Attacke unrentabel zu machen.

Ähm. Was hindert denjenigen, der Brute Force durchführt, das Script mehrmals gleichzeitig aufzurufen?

Viele Grüße,
Christian

[Roger]

moin!

Ähm. Was hindert denjenigen, der Brute Force durchführt, das Script mehrmals gleichzeitig aufzurufen?

die zeit ;)
er würde zu lange brauchen, um mit millionen versuchen erfolgreich zu sein :)
aufrufen kann er es, aber es würde einfach zu lange dauern.

gruß.
roger.

[Tom]

Hello,

er würde zu lange brauchen, um mit millionen versuchen erfolgreich zu sein :)
aufrufen kann er es, aber es würde einfach zu lange dauern.

Nein Roger. Das hängt einzig und alleine davon ab, wieviele gleichzeitige Requests der Apache beantworten mag. Bei der Standardeinstellung sind das dann ggf. 150. Bei einem großen Provider mögen das aber auch 1000 sein.

Gleichzeitig heitß hier tatsächlich, dass ein neuer Request beantwortet wird, obwohl der alte noch nicht erledigt ist.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Cheatah]

Hi,

er würde zu lange brauchen, um mit millionen versuchen erfolgreich zu sein :)
aufrufen kann er es, aber es würde einfach zu lange dauern.
Nein Roger. Das hängt einzig und alleine davon ab, wieviele gleichzeitige Requests der Apache beantworten mag. Bei der Standardeinstellung sind das dann ggf. 150.

... und damit wäre der Server nach 150 Versuchen _dicht_, Stichwort DoS-Attacke. Man könnte es auch so ausdrücken: "Hier hast Du eine Pistole, und hier ist mein Knie."

Cheatah

[Yeti]

Hi,

... und damit wäre der Server nach 150 Versuchen _dicht_, Stichwort DoS-Attacke. Man könnte es auch so ausdrücken: "Hier hast Du eine Pistole, und hier ist mein Knie."

So würde ich das nicht ausdrücken. Schließlich kann der Angreifer, wenn es seine Bandbreite zulässt, auch schon von Anfang an die Maximalanzahl an gleichzeitigen Zugriffen ausreizen. Wie gesagt, eine Sperre bei 3 (oder 10 oder...) gleichzeitigen Zugriffen über dieselbe IP ist sinnvoller.

Der Yeti

[Tom]

Hello,

So würde ich das nicht ausdrücken. Schließlich kann der Angreifer, wenn es seine Bandbreite zulässt, auch schon von Anfang an die Maximalanzahl an gleichzeitigen Zugriffen ausreizen. Wie gesagt, eine Sperre bei 3 (oder 10 oder...) gleichzeitigen Zugriffen über dieselbe IP ist sinnvoller.

Die Profis in diesem Berich haben Dank Thorn-Deamon & Co. genügend verschiedene IPs unterschiedlicher Netze zur Verfügung. Vielleicht ist Dein Server auch schon ein Mitglied einer Schläfergruppe für DDoS-Attacken. Das kann man leider auch nur noch sehr schwer erkennen. Wenn der Provider nicht ständig ein Scan fährt, um die Signaturen zu erkennen, ist alles möglich. Ich beschäftige mich seit 1996 mit diesen Dingen und habe da eigentlich in der Uni Linz einen verlässlichen Auskunftgeber für Gegenmaßnahmen gefunden.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Yeti]

Hi,

Die Profis in diesem Berich haben Dank Thorn-Deamon & Co. genügend verschiedene IPs unterschiedlicher Netze zur Verfügung. Vielleicht ist Dein Server auch schon ein Mitglied einer Schläfergruppe für DDoS-Attacken. Das kann man leider auch nur noch sehr schwer erkennen. Wenn der Provider nicht ständig ein Scan fährt, um die Signaturen zu erkennen, ist alles möglich. Ich beschäftige mich seit 1996 mit diesen Dingen und habe da eigentlich in der Uni Linz einen verlässlichen Auskunftgeber für Gegenmaßnahmen gefunden.

Um Profis zu bekämpfen sollte man auch lieber Profi-Software einsetzen mit Intrusion Detection und all so nem Kram.
Eigentlich würde ich mich sogar direkt geehrt fühlen, wenn sich einer daran versuchen sollte. ;-)

Der Yeti

[Tom]

Hello,

er würde zu lange brauchen, um mit millionen versuchen erfolgreich zu sein :)
aufrufen kann er es, aber es würde einfach zu lange dauern.
Nein Roger. Das hängt einzig und alleine davon ab, wieviele gleichzeitige Requests der Apache beantworten mag. Bei der Standardeinstellung sind das dann ggf. 150.

... und damit wäre der Server nach 150 Versuchen _dicht_, Stichwort DoS-Attacke. Man könnte es auch so ausdrücken: "Hier hast Du eine Pistole, und hier ist mein Knie."

Daher ist halt zu überlegen, ob man nach x Zugriffsversuchen nicht das Passwort automatisch ändert, dafür aber die Response-Time kurz hält und lieber einen Trigger installiert, wenn innerhalb einer gewissen Zeit zuviele Login-Requests kommen.

Der Handler kann dann den Operator warnen und der kann dann Maßnahmen ergreifen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Yeti]

Hi,

Der Handler kann dann den Operator warnen und der kann dann Maßnahmen ergreifen.

Ich will den (ehrenamtlichen) "Operator" einer Webseite sehen, der sich nachts um halb 4 von einer Warn-SMS aus dem Schlaf rütteln lässt, sich verschlafen an den Rechner schmeißt, sich eine Jolt-Cola reinzieht und den bösen Hacker bekämpft. :-)

Der Yeti

[Tom]

Hello,

Der Handler kann dann den Operator warnen und der kann dann Maßnahmen ergreifen.

Ich will den (ehrenamtlichen) "Operator" einer Webseite sehen, der sich nachts um halb 4 von einer Warn-SMS aus dem Schlaf rütteln lässt, sich verschlafen an den Rechner schmeißt, sich eine Jolt-Cola reinzieht und den bösen Hacker bekämpft. :-)

Dann verstehst Du das Prinzip nicht. Weiso sollte ein solcher Handler, der empfindlich aber nicht überempfindlich ist, nicht den Operator des Providers infomieren? Schließlich ist meistens das Gesamtsystem gefährdet.

Darüber sollte man sich aber vorher abstimmen und nicht gleich bei 3.000 Versuchen nervös reagieren.

Wenn es aber 30.000 sind, wird langsam spruchreif.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Yeti]

Hi,

Dann verstehst Du das Prinzip nicht. Weiso sollte ein solcher Handler, der empfindlich aber nicht überempfindlich ist, nicht den Operator des Providers infomieren? Schließlich ist meistens das Gesamtsystem gefährdet.

OK, das macht Sinn. Aber die sollten es ja schon selber merken, wenn jemand die gesamte Anbindung ihres Rechenzentrums verstopft.
Ansonsten schätze ich mal (ohne es versucht zu haben), dass Billighoster wie 1&1, Strato und Konsorten sich darauf nicht einlassen.

Der Yeti

[Yeti]

Hi,

Nein Roger. Das hängt einzig und alleine davon ab, wieviele gleichzeitige Requests der Apache beantworten mag. Bei der Standardeinstellung sind das dann ggf. 150. Bei einem großen Provider mögen das aber auch 1000 sein.

Gleichzeitig heitß hier tatsächlich, dass ein neuer Request beantwortet wird, obwohl der alte noch nicht erledigt ist.

Schon. Aber siehe User comment zu "sleep":
"About using sleep() after an authentication failure:

While it is true that crackers can launch multiple concurrent attempts, the number of concurrent attempts is limited to your server's maximum number of concurrent requests.  As this number is usually miniscule in comparison to the numbers of attempts a cracker would probably need to brute force a password, sleep() _does_ in fact provide effective anti-cracking benefit."

Bei hinreichend sicheren Passwörtern dauert es vielleicht 10 Millionen Versuche, bis man zu einem Ergebnis kommt.
Ohne sleep sind wir dann bei vielleicht 2 Wochen, mit sleep und 5 Sekunden Verzögerung bei 1,5 Jahren!

Der Yeti

[Yeti]

Hi,

Ähm. Was hindert denjenigen, der Brute Force durchführt, das Script mehrmals gleichzeitig aufzurufen?

Der zusätzliche Sicherheitsmechanismus, der nur maximal x (z.B. 3) gleichzeitige Zugriffe von derselben IP zulässt.
Jetzt kommst du wieder: "Und was, wenn der Angreifer Tausende Clients unter seiner Kontrolle hat?" Tja, dann hat man ohnehin ein Problem ...

Generell kann man es nicht unmöglich machen aber immerhin schon mal so schwer wie möglich.

Der Yeti

[Cheatah]

Hi,

"Und was, wenn der Angreifer Tausende Clients unter seiner Kontrolle hat?"

oder einen einzigen Client mit tausenden anonymisierenden Proxys, was bei jedem dahergelaufenen ScR1pT-k|dDi3 der Fall ist.

Generell kann man es nicht unmöglich machen aber immerhin schon mal so schwer wie möglich.

Mit erheblichem Aufwand willst Du einen grundsätzlichen Mangel Deiner eigenen Funktionalität reduzieren. Ein serverseitiges sleep() ist ein Oxymoron.

Cheatah

[Yeti]

Hi,

Mit erheblichem Aufwand willst Du einen grundsätzlichen Mangel Deiner eigenen Funktionalität reduzieren. Ein serverseitiges sleep() ist ein Oxymoron.

Also selbst nach dreimaligem Lesen verstehe ich immer noch nicht, was du mir sagen willst. Aufwand? s l e e p ( 5 ) ; sind 9 Tastenanschläge plus einen zehnten für newline.
Wenn du das sooo schlecht findest, dann erläuter uns doch mal dein total einfaches und mächtiges Sicherheitskonzept...

Der Yeti

[Cheatah]

Hi,

Also selbst nach dreimaligem Lesen verstehe ich immer noch nicht, was du mir sagen willst. Aufwand? s l e e p ( 5 ) ; sind 9 Tastenanschläge plus einen zehnten für newline.

plus der Mehraufwand, um die - nun intensiv genug besprochenen - erheblichen Nachteile dieses Vorgehens auf ein Minimum zu reduzieren.

Wenn du das sooo schlecht findest, dann erläuter uns doch mal dein total einfaches und mächtiges Sicherheitskonzept...

Auch hierzu wurden bereits Wege genannt. Und ich hoffe Du erwartest nicht, dass es _das_ _eine_ Sicherheitskonzept gibt, weder für diesen noch für einen anderen Fall :-)

Cheatah

[Yeti]

Hi,

plus der Mehraufwand, um die - nun intensiv genug besprochenen - erheblichen Nachteile dieses Vorgehens auf ein Minimum zu reduzieren.

Sorry, aber mir hat noch keiner hinreichend erklärt, warum das connection limit von z.B. 150 bei Verwendung von sleep ein Problem sein sollte und sonst nicht. Schließlich wird der Angreifer doch auch ohne sleep so viele Anfragen wie möglich absetzen.
Ach, richtig. Ohne sleep hat er schneller das Passwort gefunden und lässt den Webserver wieder in Ruhe arbeiten. :-)

Der einzige Nachteil den ich sehe ist, dass die legitimen Benutzer dann eben auch diese Zeitspanne absitzen müssen.

Wenn es so abgrundtief negativ ist, warum setzt dann z.B. GMX auf genau dieses Verfahren?

Der Yeti

[Tom]

Hello,

Sorry, aber mir hat noch keiner hinreichend erklärt, warum das connection limit von z.B. 150 bei Verwendung von sleep ein Problem sein sollte und sonst nicht. Schließlich wird der Angreifer doch auch ohne sleep so viele Anfragen wie möglich absetzen.

Hasr Du Dich denn schon hinreichend bemüht, es dank dieser Fachbegriffe selber mal zu recherchieren über die Möglochekeiten der Archivsuche und der gängigen Suchmaschinen?

Ich habe den Eindruck gewonnen, dass Du UNS dafür verantwortlich machen willst, dass Du noch doof bist. ICH habe aber keinen Ausbildungsvertrag mit Dir. Wenn es hier jemanden gibt, der einen hat, der kann ja HIER schreien.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Yeti]

Hi,
vor einiger Zeit dachte ich noch, in diesem Forum könnte man Hilfestellungen zu Problemen bekommen. So langsam schwindet diese Erkenntnis.
Entweder man wird sofort und ohne Gnade geflamet oder es meldet sich gar keiner ...

Hasr Du Dich denn schon hinreichend bemüht, es dank dieser Fachbegriffe selber mal zu recherchieren über die Möglochekeiten der Archivsuche und der gängigen Suchmaschinen?

Ja, ich habe Google und die allmächtige und vielzitierte Forensuche zu Rate gezogen. Beide haben mir nichts Brauchbares zu dem Thema liefern können.

Ich habe den Eindruck gewonnen, dass Du UNS dafür verantwortlich machen willst, dass Du noch doof bist. ICH habe aber keinen Ausbildungsvertrag mit Dir. Wenn es hier jemanden gibt, der einen hat, der kann ja HIER schreien.

Macht doch, was ihr wollt...

Der Yeti

[Yeti]

Das Einzige, was ich bei der Archivsuche gefunden habe, war ein gewisser Tom von Bitworks Braunschweig, der eine Funktion mit dem bösen "sleep"-Befehle gepostet hat! Huch!!
Der Yeti

[Tom]

Hello,

Das Einzige, was ich bei der Archivsuche gefunden habe, war ein gewisser Tom von Bitworks Braunschweig, der eine Funktion mit dem bösen "sleep"-Befehle gepostet hat! Huch!!

Na und?
Es sagt ja auch keiner, dass der nicht "normale" Anmeldeversuche reglementiern könnte.

Aber HTTP ist eben in der Lage, diverse quasi-parallele Versuche zu bedienen. Und da fürht ein sleep() eben nur in das Connection-Limit.

Was wolltest Du sonst noch wissen?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Yeti]

Hi,

Was wolltest Du sonst noch wissen?

Wie du bei 30 Millionen nötigen Anfragen fürs Brute Forcing verhinderst, dass der Server trotzdem seine 150 erreicht.
Zugegeben, der Angreifer muss erstmal so viele schaffen (wohingegen er bei Verwendung von sleep x Sekunden mehr Zeit hat...).

Aber da ich deine Intelligenz beleidigt habe, will ich dich auch gar nicht weiter belästigen.

Der Yeti

[Z.N.S.]

abend,

Ich habe den Eindruck gewonnen, dass Du UNS dafür verantwortlich machen
willst, dass Du noch doof bist. ICH habe aber keinen Ausbildungsvertrag mit
Dir. Wenn es hier jemanden gibt, der einen hat, der kann ja HIER schreien.

und wer holt dich mal vom ross?

mfg,
(tanz das)
Z.N.S.

[Tom]

Hello,

Ich habe den Eindruck gewonnen, dass Du UNS dafür verantwortlich machen
willst, dass Du noch doof bist. ICH habe aber keinen Ausbildungsvertrag mit
Dir. Wenn es hier jemanden gibt, der einen hat, der kann ja HIER schreien.
und wer holt dich mal vom ross?

Von welchem Ross?

Ist das nicht der normale Tenor, wenn jemand nicht selber mitwirkt?
Ich muss mich doch freuen über soviel plötzlichen Altruismus.
Aber ich wundere mich auch darüber, dass Du keinen Lösungsvorschlag dranhängst. Nun lass mal sehen, wie gut DU zu Fuß (also ohne Ross) bist. ;-)

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Z.N.S.]

abend,

Ist das nicht der normale Tenor, wenn jemand nicht selber mitwirkt?

_dein_ tenor, fürwahr, untermalt mit zahlreichen binsen.

Ich muss mich doch freuen über soviel plötzlichen Altruismus.

altruismus, der in deinem posting nicht zu finden war. da hätte ich mich auch gefreut.

Aber ich wundere mich auch darüber, dass Du keinen Lösungsvorschlag dranhängst.

wie du wohl unschwer erkennen konntest, war ich an der lösung nicht interessiert.

Nun lass mal sehen, wie gut DU zu Fuß (also ohne Ross) bist.

ich bin bei leibe nicht auf postpupertären schwanzvergleich angewiesen.

ließ dir dein ausgangsposting, welches mich zu der kritik geführt hat, noch
einmal in ruhe durch. und sag mir dann allen ernstes, dass dein posting nicht
a) unangemessen
b) kindisch
c) egoistisch
d) unnötig
war ?

(tanz das)
Z.N.S.

[Christian Kruse]

Hallo Tom,

das war mal wieder so ein richtiges Arschloch-Posting.

Grüße,
 CK

[Tom]

Hello,

das war mal wieder so ein richtiges Arschloch-Posting.

Ach, wenn Du wüsstest...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Yeti]

Hi,
ja, gibt es: http://php.net/sleep bzw. http://php.net/usleep.
Setze es auch erfolgreich ein und anscheinend "schläft" PHP in der Zeit wirklich, zumindest laut Prozessorlast. So wie es sein muss.
Gruß,
der Yeti

[Christian Kruse]

Hallo Yeti,

Setze es auch erfolgreich ein und anscheinend "schläft" PHP in der
Zeit wirklich, zumindest laut Prozessorlast. So wie es sein muss.

Das ist abhaengig von der Plattform. Es soll durchaus Plattformen
geben, wo sleep() mittels eine busy waits umgesetzt ist.

Grüße,
 CK