Passwortseite mit Übergabe an .htacess

[artlow]

Hallo zusammen,

habe einen Passwortgeschützten Bereich mittels .htacess realisiert.
Möchte nun aber das beim Menüpunktaufruf, nicht direkt die Passwortabfrage des .htacess erscheint, sondern erstmal eine HTML-Seite mit den Textfelder USERNAME und PASSWORT. Diese sollen dann irgendwie zur .htaccess-Abfrage übermittelt werden, und die .htacess Abfrage gar nicht mehr erscheinen.
Leider habe ich keine Ahnung wie man das macht?
Jemand sowas schonmal gemacht?

MfG
artlow

[Cheatah]

Hi,

habe einen Passwortgeschützten Bereich mittels .htacess realisiert.

zwar ist der Name konfigurierbar, aber üblicherweise heißt die Datei ".htaccess" mit zwei "c".

erstmal eine HTML-Seite mit den Textfelder USERNAME und PASSWORT. Diese sollen dann irgendwie zur .htaccess-Abfrage übermittelt werden, und die .htacess Abfrage gar nicht mehr erscheinen.

Der komplexe Mechanismus der Basic bzw. Digest Authentication lässt sich nicht mit einfachen Mitteln übersteuern. Es braucht dazu ein Servermodul, welches den Mechanismus verändert. Wenn PHP als solches installiert ist (also nicht im CGI-Modus), ist es auf diesem Weg möglich, eine Formulareingabe entsprechend zu verarbeiten - wenn dieses Dir nicht zur Verfügung steht, wirst Du die Authentifizierung genau so vornehmen lassen müssen, wie der User es von zigtausend Seiten kennt.

Cheatah

[artlow]

Hallo.

so schwer kann das ganze ja auch nicht sein. Gib mir mal einen Tip.
Und du meinst mit Perl wäre das nicht möglich, im Prinzip müsste ich doch nur die Daten übermittelt bekommen (stelle mir das ähnlich wie bei einem Kontaktformular vor), nur weiss ich nicht wie ich das .htaccess ansprechen soll....das es nicht erscheint und ich die Daten übergebe.......????????
Aber denke mal das es ein Modul dazu gibt.....ist ja ne Standardsache die eigentlich jeder mal brauchen kann....Braucht man also noch nicht mal selbst proggen......

Danke im voraus.

MfG
artlow

[Sven Rautenberg]

Moin!

so schwer kann das ganze ja auch nicht sein. Gib mir mal einen Tip.
Und du meinst mit Perl wäre das nicht möglich, im Prinzip müsste ich doch nur die Daten übermittelt bekommen (stelle mir das ähnlich wie bei einem Kontaktformular vor), nur weiss ich nicht wie ich das .htaccess ansprechen soll....das es nicht erscheint und ich die Daten übergebe.......????????
Aber denke mal das es ein Modul dazu gibt.....ist ja ne Standardsache die eigentlich jeder mal brauchen kann....Braucht man also noch nicht mal selbst proggen......

Geht aber nicht.

Die Anmeldedaten von .htaccess werden in speziellen Headern des HTTP-Requests mitgeschickt. Da kommt man von Seiten des Browsers _nicht_ ran - es sei denn, du schreibst dir einen eigenen Browser, bei dem das geht.

Außerdem: Das Anmeldefenster, was du nicht willst, wird vom Browser deswegen angezeigt, weil eine spezielle Serverreaktion erfolgt, die ebenfalls spezielle HTTP-Header enthält.

Außerdem ist die Authentifizierung mit .htaccess keine einmalige Sache, sondern der Browser merkt sich Username und Paßwort und schickt diese Daten bei allen folgenden Requests immer wieder mit. Bei einem Formular würden die Daten nur einmal mitgeschickt - und es ist keinerlei Möglichkeit im Standard vorgesehen, daß der Browser irgendwelche vom Server mitgeschickten Daten als Anmeldedaten wieder zurückschickt.

Mit anderen Worten: Es geht nicht. Hat auch Sicherheitstechnische Gründe, damit dem Benutzer klar ist, welche Bedeutung die Eingabe der Daten hat.

- Sven Rautenberg

[artlow]

Hallo.

das ist alles richtig was du schreibst.

Mir ist es jedoch egal, ob die Daten gesavt werden oder nicht. Dann soll der User die Daten eben jedesmal neu eingeben.
Andere Seiten haben das doch auch realisiert.

Ich möchte nur wissen, ob das mit PERL möglich ist oder ob ich in jedem Fall PHP benötige.

[GONZO]

Hallo artlow,

Ich möchte nur wissen, ob das mit PERL möglich ist oder ob ich in jedem Fall PHP benötige.

Natürlich geht das.
Das hat dann aber nichts mehr mit .htaccess zu tun, sondern du mußt
dann deinen eigenen "Schutz" schreiben, der mit Sessions arbeitet.
Jede Seite die du schützen willst muß sich also selber schützen.

Pseudocode an jedem Seitenanfang:

if( ! sesseion_etabliert)
{
 bitte_usernamen_und_passwort_eingeben
 user_und_passwort_gueltig
 session_etablieren
}

Dazu kommt dann noch ein mechanismus die session für beendet
zu erklären. Entweder durch timeout oder logout.

CYa
GONZO

[artlow]

Hi Gonzo,

wie sicher ist denn das dann?
Hast du da schonmal was gehackt, was du mir empfehlen könntest?

MfG
artlow

[Cheatah]

Hi,

wie sicher ist denn das dann?

das hängt von Dir ab. Sicher ist, dass "sicher" kein Zustand ist, kein Ziel - sondern ein Weg.

Hast du da schonmal was gehackt,

Ich halte Gonzo eigentlich nicht für einen Hacker.[1]

Cheatah

[1] Schon allein wegen der eher ungeeigneten Schnabelform ;-)

[artlow]

lacht, war auch eher "hacken" im Sinne von schonmal gemacht....
schade ihr schreibt immer irgendwas "kluges" aber sinnvolle Informationen erhalte ich dadurch auch leider nicht.

naja, muss ich eben selbst mal gucken....und wieder was lustiges basteln...Trotzdem danke.

[Cheatah]

Hi,

lacht, war auch eher "hacken" im Sinne von schonmal gemacht....

ich nehme an, fast jeder hier hat schon das eine oder andere Mal eine Authentifizierung in Programmcode untergebracht.

schade ihr schreibt immer irgendwas "kluges" aber sinnvolle Informationen erhalte ich dadurch auch leider nicht.

Das erinnert mich an den Film "Die Götter müssen verrückt sein": Ein einheimischer erzählt einer "westlichen" Frau anhand von Spuren im Sand, was hier kürzlich abgegangen sein muss. Sie verstand aber offenbar nichts. Kommentar des Sprechers: "Wahrscheinlich konnte sie nicht lesen."

Cheatah

[Andreas]

Hi

lacht, war auch eher "hacken" im Sinne von schonmal gemacht....
schade ihr schreibt immer irgendwas "kluges" aber sinnvolle Informationen erhalte ich dadurch auch leider nicht.

naja, muss ich eben selbst mal gucken....und wieder was lustiges basteln...Trotzdem danke.

^^^^^^
Daher wahrscheinlich der Name SELFforum ;-)
Aber ich hab oben mal was geschrieben:
http://forum.de.selfhtml.org/?m=74062&t=13365
Was ähnliches hatt ich (und bestimmt schon viele andere) ja auch mal gefragt:
http://forum.de.selfhtml.org/archiv/2002/1/3631/#m20812(vielleicht verständlich das die profis hier icht alles 10 mal erklären wollen, wenn man es einfach im Archiv nachlesen könnte, oder?), auch immer sehr beliebt:
http://selfsuche.teamone.de/cgi-bin/such.pl?suchausdruck=Sicherheit+htaccess&feld=alle&index_1=on&index_2=on&index_3=on&index_4=on&hits=100

In diesem Sinne -

Grüße
Andreas

[Andreas]

Hi!

wie sicher ist denn das dann?
Hast du da schonmal was gehackt, was du mir empfehlen könntest?

Das wirklich sicher zu machen traue ich mir z.B. nicht annähernd zu. Du kannst zwar vor jeder Seite prüfen, ob die zugangsdaten korekt sind, und entsprechend reagieren, aber die Benutzerdaten müsen auchsicher sein, und das ist ein Problem! zum einen müssen solche Daten unbedingt per SSL übertragen werden, sonst hast Du schon bei der Übertragung eine riesen Sicherheitslücke. Außerdem mußt Du die zugangsdaten ja auch irgendwo speichern, damit du die Eingabe auch kontrollieren kannst. Wenn Du z.B. ein passwort.txt anlegts, in der Du die Daten speicherst, darf die nicht direkt über das Internet erreichbar sein, auch htaccess bringt bei sowas nicht so viel. Außerdem muß der restliche quellcode der Seite so sicher sein, das niemand irgendwo durch irgendwelche tricks Code einschleusen kann, oder dafür sorgend, dass die Datei mit rel. Verweisen doch angezeigt wird, obwohl eigentlich ja nicht erreichbar über das www. Selbiges gilt für eine Datenbank, ist ja ganz praktisch, aber wenn irgendjemand zugriff darauf erlangt, ob über irgndwelche unnötigen Standardbenutzer, oder über ein anderes Sicherheitsloch auf der rextlichen Internetseite, nützt Dir das ganze herzlich wenig. Außerdem, wenn Du nicht willst, das der Benutzer die Daten auf jeder Seite neu eingeben soll, mußt Du die Daten irgendwie speichern, ob in deiner Session, Cookies oder wie auch immer, an solche Daten kann auch jemand gelangen.
Das ist alle hochkomplitziert, und pot. Angreife haben oft irgendwelche Tools, die automatisch alle häufigen Anfängerfehler oder bekannte Sicherheitslücken ausnutzen. Dagegen sehe ich mit meinen sehr spärlichen Programmiererfahrungen sehr blaß gegen aus.
Vielleicht haben die Profis hier ja noch den ein oder anderen Tipp, worauf man achten sollte, würde mich auch sehr interessieren!

Ich kann Dir bei wirklich kritsichen Bereichen nur zu htaccess raten, alles andere ist ein Sicherheitsrisiko. Wenn Du jetzt nur einen privaten Bereich z.B. in eine, Forum hast, dann ist es nicht ganz so wild, ertmal kann nicht viel passieren, außerdem lohnt sich da kein Angriff.

Viele Grüße
Andreas

[Andreas]

... und nochwas na die Fachleute, mir war gerade ein besonders kritisches Beispiel eingefallen - Onlinebanking!

Aber dann sagt mir mal - warum sollten gerade die Banken auf htaccess verzichten? Mir ist keine Bank bekannt, die htaccess benutzt! Und ich nehme mal an die haben sich schon Gedanken über Sicherheit gemacht. Was machen die anders?

Viele Grüße
Andreas

[Cheatah]

Hi,

Aber dann sagt mir mal - warum sollten gerade die Banken auf htaccess verzichten?

warum nicht? Die Annahme, Basic/Digest Authentication würde das Maximum der möglichen Sicherheit darstellen, ist falsch.

Und ich nehme mal an die haben sich schon Gedanken über Sicherheit gemacht. Was machen die anders?

Banken verlassen sich einerseits auf proprietäre Systeme (meist Java-Applets - natürlich stellt eine "nicht standardisierte Kommunikation" nur eine geringe Hürde dar; der Vorteil liegt aber in erweiterten Möglichkeiten im Hinblick auf Client-Identifikation), auf SSL, und besonders auf Einmal-Passwörter (TANs). Wurde ein TAN verwendet, bringt er niemandem mehr etwas, selbst wenn es jemandem trotz SSL gelingen sollte, ihn abzufangen.

Ach so, eine vernünftige Passwortabfrage beim Login bekommen bei Banken angestellte Programmierer auch hin :-)

Cheatah

[Andreas]

Hallo!

Aber dann sagt mir mal - warum sollten gerade die Banken auf htaccess verzichten?

warum nicht? Die Annahme, Basic/Digest Authentication würde das Maximum der möglichen Sicherheit darstellen, ist falsch.

Ja, das ist mir wohl bewußt, aber wenn  ich Sven richtig verstanden habe, haben alle anderen System den Nachteil, das man sich immer mehr schlecht als recht behelfen muß(wie im anderen Posting von mir :-)), den Client auf der nächsten Seite wiederzuerkennen, da ja keine Benutzerdaten mitgesendet werden.

Banken verlassen sich einerseits auf proprietäre Systeme (meist Java-Applets - natürlich stellt eine "nicht standardisierte Kommunikation" nur eine geringe Hürde dar; der Vorteil liegt aber in erweiterten Möglichkeiten im Hinblick auf Client-Identifikation), auf SSL,

Ach, das haben tatsächlich manche, damit koppelt man sich natürlich von den Möglichkeiten der Browser los und ist total frei, oder?

und besonders auf Einmal-Passwörter (TANs). Wurde ein TAN verwendet, bringt er niemandem mehr etwas, selbst wenn es jemandem trotz SSL gelingen sollte, ihn abzufangen.

Ja, aber genau so gut könnte man das Passwort mitbekommen, und dann kann man schonmal einblicke auf ein Fremdes Konto nehmen, IMHO ein großer Unterschied als wenn jemand in den privaten Bereich eines Forums eindringt und irgendwelche spaßigen Nachrichten liest!

Ach so, eine vernünftige Passwortabfrage beim Login bekommen bei Banken angestellte Programmierer auch hin :-)

vermutlich :-)

Grüße Andreas

[Cheatah]

Hi,

Aber dann sagt mir mal - warum sollten gerade die Banken auf htaccess verzichten?
warum nicht? Die Annahme, Basic/Digest Authentication würde das Maximum der möglichen Sicherheit darstellen, ist falsch.
Ja, das ist mir wohl bewußt, aber wenn  ich Sven richtig verstanden habe, haben alle anderen System den Nachteil, das man sich immer mehr schlecht als recht behelfen muß(wie im anderen Posting von mir :-)), den Client auf der nächsten Seite wiederzuerkennen, da ja keine Benutzerdaten mitgesendet werden.

genau darauf wollte ich hiermit hinweisen:

Banken verlassen sich einerseits auf proprietäre Systeme (meist Java-Applets - natürlich stellt eine "nicht standardisierte Kommunikation" nur eine geringe Hürde dar; der Vorteil liegt aber in erweiterten Möglichkeiten im Hinblick auf Client-Identifikation),

Wenn sich ein Applet mittels "definierter Kommunikation" beim Server anmeldet, kann es eine eindeutige Kennzeichnung bekommen.

Ach, das haben tatsächlich manche, damit koppelt man sich natürlich von den Möglichkeiten der Browser los und ist total frei, oder?

Jein. Es ist von der Funktionalität her ein riskantes Gewässer - Java kann deaktiviert/nicht vorhanden sein, oder auch ziemlich makaber installiert (man schmeiße nur mal den IE auf einen armen, unschuldigen Mac...), und alles was über HTTP hinausgeht, kann ohne weiteres an einer Firewall hängenbleiben. Gesetzt den Fall es funktioniert, sind die Möglichkeiten aber enorm.

Ja, aber genau so gut könnte man das Passwort mitbekommen,

Das ist sogar unwahrscheinlicher als bei Authentication: Das Applet kann weiterhin SSL verwenden, aber das Passwort bereits verschlüsselt (ob crypt(), MD5 oder etwas anderes) übertragen.

und dann kann man schonmal einblicke auf ein Fremdes Konto nehmen,

Das ist wie gesagt von den TANs abhängig, die der User nur schriftlich erhält; bzw. davon, welche Aktionen ohne TAN möglich sind. Wenn ich in meiner Bank am Überweisungs-Automaten vergesse, mich abzumelden, kann der nächste auch meinen Kontostand einsehen - und hat sogar mehr davon, weil er mich kurz mal überfallen und die Karte rauben kann, wenn ihm gefällt, was er sieht.

IMHO ein großer Unterschied als wenn jemand in den privaten Bereich eines Forums eindringt und irgendwelche spaßigen Nachrichten liest!

Du weißt vorher eben nie, ob es bei spaßigen Nachrichten bleibt. Sicher, bei Homebanking ist Dir vorher klar, dass es sich um vitale Daten dreht. Dadurch solltest Du aber nicht vergessen, dass dies _immer_ passieren kann, auch in einem Forum. Wenn Du nicht gewillt (bzw. "gekonnt", wenn Zeit fehlt usw.) bist, einen Bereich von Anfang an maximal sicher zu gestalten, solltest Du ihn lieber gleich vollständig unsicher gestalten. Das "führt weniger in Versuchung".

Cheatah

[Cheatah]

Schon wieder 'n P.S.:

Wenn Du nicht gewillt (bzw. "gekonnt", wenn Zeit fehlt usw.) bist, einen Bereich von Anfang an maximal sicher zu gestalten, solltest Du ihn lieber gleich vollständig unsicher gestalten. Das "führt weniger in Versuchung".

Aus genau diesem Grund gilt eine Firewall übrigens bei Profis sogar als Sicherheits_risiko_, wenn sie nicht von gekonnter Hand konfiguriert wurde. Vergleiche https://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html, die FAQ von news:de.comp.security.firewall.

Cheatah

[Andreas]

Hi!

Aus genau diesem Grund gilt eine Firewall übrigens bei Profis sogar als Sicherheits_risiko_, wenn sie nicht von gekonnter Hand konfiguriert wurde. Vergleiche https://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html, die FAQ von news:de.comp.security.firewall.

Sehr interessanter Link ist das! Habe heute etwas verspätet erstmal wieder einen Virenscanner installiert, hatte 6 Würmer und 3 Trojaner installiert! Da ich weiß was man damit machen kann - hier meine Sorge um die Sicherheit bei den Clients :-) Vor allem da sich die meisten Leute noch viel weniger auskenne als ich! Naja.
Grüße
Andreas

[Cheatah]

Hi,

hatte 6 Würmer und 3 Trojaner installiert!

ts, warum machst Du das? :-)

Da ich weiß was man damit machen kann - hier meine Sorge um die Sicherheit bei den Clients :-)

*g*

Was mal ein _wirklich_ sinnvoller Virus wäre: Einer, der (natürlich!) nur Microsoft-Programme infiziert, sich erst mal schnell verbreitet, dann das betreffende Programm deinstalliert und eine Alternative auf die Platte haut. Name: "LastVirusEver" ;-)

Cheatah

[Peter Thomassen]

Hi,

Ja, aber genau so gut könnte man das Passwort mitbekommen,

Das ist sogar unwahrscheinlicher als bei Authentication: Das Applet kann weiterhin SSL verwenden, aber das Passwort bereits verschlüsselt (ob crypt(), MD5 oder etwas anderes) übertragen.

http://pajhome.org.uk/crypt/md5/ - das geht also auch schon
clientseitig, oder nicht?

Bye,
Peter

[Cheatah]

Hi,

Das ist alle hochkomplitziert, und pot. Angreife haben oft irgendwelche Tools, die automatisch alle häufigen Anfängerfehler oder bekannte Sicherheitslücken ausnutzen. Dagegen sehe ich mit meinen sehr spärlichen Programmiererfahrungen sehr blaß gegen aus.

aufgrund der sehr klaren Vorstellungen von Sicherheit und potentiellen Problemen, die Du hier präsentierst, muss ich Dir sagen, dass ich Dir dies nicht glaube.

Vielleicht haben die Profis hier ja noch den ein oder anderen Tipp, worauf man achten sollte, würde mich auch sehr interessieren!

Das Wesentliche scheint Dir bereits bewusst zu sein: Sicherheit ist kein Ziel, sondern ein Weg, der immer wieder ein Stückchen weiter gegangen werden muss. Bei den meisten der Schritte ist es hilfreich, sich den Grundsatz "whitelist is better than blacklist" vor Augen zu haben: Lieber nur das definieren, was erlaubt ist, und den Rest ablehnen; als das zu definieren, was _nicht_ erlaubt ist (und nämlich mit Sicherheit (ha, ha :-) etwas übersehen).

Ich kann Dir bei wirklich kritsichen Bereichen nur zu htaccess raten, alles andere ist ein Sicherheitsrisiko.

Nö. Aber Basic/Digest Authentication ist etabliert und bewährt - eine Alternative mit ähnlich geringem Risiko zu schaffen, kostet verdammt viele Ressourcen.

Wenn Du jetzt nur einen privaten Bereich z.B. in eine, Forum hast, dann ist es nicht ganz so wild, ertmal kann nicht viel passieren, außerdem lohnt sich da kein Angriff.

Es ist leicht, vorher zu sagen, ein Angriff würde nicht lohnen. Wenn dann aber plötzlich etwas lohnenswertes da ist, ist es ziemlich schwer, den Sicherheitsmechanismus nachträglich zu verbessern. Lieber sollte man sich von Anfang an an der _maximalen_ Sicherheit orientieren.

Cheatah

[Andreas]

Hi Cheatah!
Das geht ja runter wie Öl... ;-)
Waren mein bisher hauptsächlich im SELFforum gesammeltes Wiissen bzgl. Sicherheit. Aber mir fehlt noch ne ganze Menge, vor allem Sicherheitslöcher auf der Homepage selbst.
Eine Frage zu htaccess:
Die Passwörter werden auf dem Server ja verschlüsselt gespeichert. Wie funktioniert das dann bei der Eingabe, wird das was in das Fenster eingegeben wird direkt als username:crypt(passwort) im Arbeitspeicher abgelegt, oder im Klartext, und auch im Klartext übertragen, wenn man kein SSL benutzt?
Und noch eine Frage wegen das anderen postings: Du sagst ein Problem ist wenn die SessionID in den Log-Files irgendwelcher Proxies... stehen, korrekt? Aber die Session wird doch rel schnell wieder gelöscht, wenn nicht mehr benötigt, das müßte also sehr zeitnah passieren, oder?

Und wenn ich SSL verwende, wird dieses Risiko dann ausgeschaltet? Was steht dann  in den Refers? Der Proxy... muß aber doch irgendwie wissemn, wohin er weiterlieten soll, un dwenn der das weiß kann das doch auch geloggt werden, oder?

Um das alles noch etwas sicherer zu machen, könnte ich ja evtl den kpl. HTTP_USER_AGENT verwenden. Ich hab mal in der phpinfo() geguckt, was wir da so alles schönes haben, in Frage kämen meiner Meinung:
HTTP_USER_AGENT - sehr verscheiden - gut geeignet, oder?
HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?
REMOTE_ADDR - auch gut, aber was ist mit Proxys? Kann es nicht vorkommen, das die Adresse während des Besuches wechselt? ich meine jetzt nicht dyn IP-Vergabe, da ist die session eh zu Ende, oder? Wie ist das mit der IP?
REMOTE_PORT Da weiß ich nicht, ob der immer gleich bleibt, wie ist das, wonach werden die Ports aufgeteilt?

Es reicht ja immer zu wissen, ob sich eher die Session beenden würde, als das sich z.B. der Port ändert. Weißt Du wie das ist? OK, von diesen Daten speichere ich dann eine bestimmte Kombination in der Session und das prüfe ich jedesmal, oder? Hat es Sinn, das noch mit MD5() zu verschlüsseln?

Vielen Dank schonmal!

Viele Grüße
Andreas

[Cheatah]

Hi,

Das geht ja runter wie Öl... ;-)

Öl, Moment, das kenne ich. Nichts verraten! ...Ah, da ist es ja:

"Öl: Eines der wenigen zweibuchstabigen Wörter, die mit 'Ö' beginnen und auf 'l' enden."

Ja, genau :-)

Waren mein bisher hauptsächlich im SELFforum gesammeltes Wiissen bzgl. Sicherheit.

Es ist schön zu sehen, dass hier nicht nur Leute mitlesen, sondern auch von dem Gelesenen profitieren.

Aber mir fehlt noch ne ganze Menge, vor allem Sicherheitslöcher auf der Homepage selbst.

Klar - das nennt sich Erfahrung. Trotzdem, Du bist Dir der Bedeutung des Begriffes "Sicherheit" schon bewusst. Ich traue Dir zu, einen "sauberen" Mechanismus zu entwickeln.

Die Passwörter werden auf dem Server ja verschlüsselt gespeichert.

Nicht auf allen Systemen. Wie erwähnt liegen bei Windows ("due to excessive paranoia") die Passwörter im Klartext vor. Da der Client dies nicht erraten kann, hat er grundsätzlich nur die ungecryptete Version.

Auch aus einem anderen Grund ist dies notwendig: crypt() funktioniert mit einem zweibuchstabigem Salt, welches auch die ersten zwei Zeichen des Ergebnisses ergibt. Der Server müsste also praktisch seine Passwörter dem Client übertragen, damit dieser die richtige Verschlüsselung wählen kann.

und auch im Klartext übertragen, wenn man kein SSL benutzt?

Ja, genau das. Der Server cryptet "bei Bedarf"; bis dahin gibt es keine Extra-Verschlüsselung für diesen Mechanismus.

Du sagst ein Problem ist wenn die SessionID in den Log-Files irgendwelcher Proxies... stehen, korrekt? Aber die Session wird doch rel schnell wieder gelöscht, wenn nicht mehr benötigt, das müßte also sehr zeitnah passieren, oder?

Richtig. Allerdings ist eben nicht ausgeschlossen, dass jemand kurzfristig (Referrer-Logs sind dabei eigentlich gefährlicher, auch weil sie jeder User haben kann, nicht nur Admins - und was Browser bisweilen alles als Referrer ansehen... mein lieber Mann...) das Logfile "benutzt" und dann in die noch gültige Session gelangt. Hab ich selbst mehr als ein Mal geschafft, aus purem Zufall - in einem Fall bin ich dann sogar an das Passwort des Users gekommen.

Und wenn ich SSL verwende, wird dieses Risiko dann ausgeschaltet?

Nein. Sicherheit ist niemals erreichbar; Risiken sind nur minimierbar. Die SSL-Verschlüsselung wird durch einen Handshake ausgehandelt - auch dieser kann abgefangen werden.

Was steht dann  in den Refers?

"Eine" URL; idealerweise die, von der aus die Ressource angefordert wurde - manchmal aber einfach irgend eine.

Der Proxy... muß aber doch irgendwie wissemn, wohin er weiterlieten soll,

Der Referrer hat mit Proxies nichts zu tun; abgesehen davon, dass einige dort reinschreiben, was sie wollen.

HTTP_USER_AGENT - sehr verscheiden - gut geeignet, oder?

Ja; aber theoretisch kann dieser von Proxies etc. requestindividuell verändert werden - mir ist der Fall zwar nicht bekannt, aber damit würdest Du eine Session unmöglich machen.

HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?

Naja, vor allem wenig nutzbar. Es dürfte sich meist um ein von der Browser-Hauptversion abhängiges Set handeln, also wenig individuell.

REMOTE_ADDR - auch gut, aber was ist mit Proxys?

Eine IP-Adresse ist nicht eineindeutig einem User zuzuordnen; aber wenn während einer Internet-Session der Proxy des Users wechselt, dann hat dieser entweder seine Konfiguration geändert, oder benutzt einen Anonymizer. In beiden Fällen muss er meines Erachtens mit eingeschränkter Funktionalität rechnen, ist also "selbst schuld".

REMOTE_PORT Da weiß ich nicht, ob der immer gleich bleibt, wie ist das, wonach werden die Ports aufgeteilt?

Weiß ich ehrlich gesagt nicht.

Hat es Sinn, das noch mit MD5() zu verschlüsseln?

Nein. Diese Daten sind nicht geheim; vor allem werden sie eh im Klartext (bzw. SSL-verschlüsselt) übertragen, ohne dass Du es beeinflussen kannst.

Cheatah

[Cheatah]

Noch was:

REMOTE_ADDR - auch gut, aber was ist mit Proxys?
Eine IP-Adresse ist nicht eineindeutig einem User zuzuordnen;

Vor allem ist sie nicht fälschbar. Diese Angabe zu verwenden schränkt den Kreis der potentiellen "Missbräucher" gewaltig ein - nämlich auf diejenigen, die hinter dem selben Proxy sitzen. Effektiv dürfte damit höchstens noch der Systemadministrator in Frage kommen, also "Spionage innerhalb der Firma", Mitarbeiterkontrolle. Der Rest der relevanten Header ist fälschbar (wie gesagt, von REMOTE_PORT weiß ich es nicht) und damit auch keine Hürde, wenn es erst mal so weit gekommen ist.

Cheatah

[Andreas]

Noch was:

Warum denn nicht den HTTP_USER_AGENT??? Solange der sich über die Session nicht verändert (oder nicht existiert)ist doch alles klar, oder? Ich will nur nicht riskieren, das die hälfzte der leute andauernd wegen solchen Sicherheits-Featureas rausfliegt!

REMOTE_ADDR - auch gut, aber was ist mit Proxys?
Eine IP-Adresse ist nicht eineindeutig einem User zuzuordnen;

Vor allem ist sie nicht fälschbar. Diese Angabe zu verwenden schränkt den Kreis der potentiellen "Missbräucher" gewaltig ein - nämlich auf diejenigen, die hinter dem selben Proxy sitzen. Effektiv dürfte damit höchstens noch der Systemadministrator in Frage kommen, also "Spionage innerhalb der Firma", Mitarbeiterkontrolle. Der Rest der relevanten Header ist fälschbar (wie gesagt, von REMOTE_PORT weiß ich es nicht) und damit auch keine Hürde, wenn es erst mal so weit gekommen ist.

Zu REMOTE_ADRESS kann ich nur folgendes sagen. Ich hatte mal nicht daran gedacht, das ich die Domain bei einem anderen Provider hatte, als die eigentliche Homepage und da umgeleitet wurde, wahrscheinlich über einen Proxy, denn komischerweise hatten alle Leute dieselbe REMOTE_ADRESS, und das war die des weiterleitenden Providers!
Das kann ich zwar verhindern, aber kann sowas nicht auch zwichen durch passieren, ohne dass ich Einfluß darauf habe?
Aber das sieht mir auch schon recht sicher aus. Aber wenn man einmal eine Verbindung hergestellt hat, ist ja schön und gut, wenn da 15 Startionen zwischen sind, kann  es nicht sein das sich da von selbst irgend ein weg ändert, über einen anderen Proxy? Ich muß gleich nochmal nachgucken, ich meine aber ich hätte es mal gehabt, das gleiche SessionID aber verschiedene IP Adresse in den Logs standen?!?!? Oder kann das nicht sein?
Nochmal kurz zur Fäkschungssicherheit, ich denke man kann ALLES was man dem Server schickt beeinflussen, wenn man sich da entsprechend auskennt. Mit der IP ist zwar erstmal dumm wenn man die eigene "ändert", denn dann kommen die Antworten woanders an, oder? Gibt es tatsächlich keine Möglichkeit, da irgendeinen bösen proxy oder was weiß ich zwischenzuhängen, und so irgendwie trotz falscher IP (indem man so tut als hätte man die andere IP, und die Antworten wie auch immer abfängt?) komunizieren zu können?

Aber was Refferer-Logs sind verstehe ich jetzt gar nicht mehr. Ich dachte das wären die "normalen" Apache-Logfiles?! Was hat das mit verschiedenen Benutzern zu tun? Wie kann man bitte "eigene" Refferer-Logs haben, und vor allem wo? Meine eigenen Refferer bringen mir da ja nichts!

Viele Grüße
Andreas

[Cheatah]

Hi,

Warum denn nicht den HTTP_USER_AGENT???

der Header kann beliebig verändert, also auch z.B. von einem Proxy mit dem Timestamp versehen werden. In dem Fall würde die Erkennung versagen.

Solange der sich über die Session nicht verändert

Das ist eben nicht gewährleistet; und der User wird i.d.R. auch nicht merken, wenn sich da was verändert. Bei einer neuen IP weiß er ja zumindest, dass er sich neu eingeloggt hat oder so :-)

(oder nicht existiert)

Das wäre auch kein Problem - solange der Leerstring konstant bleibt.

Ich will nur nicht riskieren, das die hälfzte der leute andauernd wegen solchen Sicherheits-Featureas rausfliegt!

Die Hälfte wird es nicht sein, sondern nur die absolute Ausnahme. Dennoch: Der User-Agent ist als Erkennungsindiz sinnvoll bei sowas wie einer Counter-Reloadsperre, wenn es nichts ausmacht, nicht wiedererkannt zu werden. Bei allem, was einen Login erfordert, möchte der User zu Recht nicht ständig seine Daten neu eingeben müssen - das ist nämlich evtl. auch wieder ein Sicherheitsrisiko, oder zumindest scheint es so.

denn komischerweise hatten alle Leute dieselbe REMOTE_ADRESS, und das war die des weiterleitenden Providers!

Das ist dann aber ein Problem, dass mit dem Webspace zusammenhängt, und ergo lösbar ist: spätestens durch einen Providerwechsel. Sowas musst Du nur einmalig sicherstellen, und brauchst es somit bei einem sicherheitsrelevanten Algorithmus nicht weiter zu beachten. Wichtig ist, was von Clientseite aus auf welche Weise zu Dir getragen wird.

Das kann ich zwar verhindern, aber kann sowas nicht auch zwichen durch passieren, ohne dass ich Einfluß darauf habe?

Nur wenn Dein Provider radikal am System etwas verändert. Sprich Dich ggf. mit ihm ab (schriftlich).

wenn da 15 Startionen zwischen sind, kann  es nicht sein das sich da von selbst irgend ein weg ändert, über einen anderen Proxy?

Normalerweise verbindet sich ein Proxy nicht zu einem anderen Proxy - zumindest nicht willkürlich. Es mag gerne sein, dass mehrere Proxies auf dem Weg zwischen einem bestimmten User und "dem Internet"[tm] liegen; aber dies darf jeweils als definiert angesehen werden. Für die Dauer der Verbindung hat ein User immer dieselbe IP. Die bereits erwähnte "selbst schuld"-Ausnahme sind Anonymizer.

Nochmal kurz zur Fäkschungssicherheit, ich denke man kann ALLES was man dem Server schickt beeinflussen, wenn man sich da entsprechend auskennt. Mit der IP ist zwar erstmal dumm wenn man die eigene "ändert", denn dann kommen die Antworten woanders an, oder?

Ja, so in etwa.

Gibt es tatsächlich keine Möglichkeit, da irgendeinen bösen proxy oder was weiß ich zwischenzuhängen,

Klar, wenn dieser die IP des Users hat, als der man sich einloggen möchte - und das ist hinreichend unwahrscheinlich. Innerhalb des Session-Timeouts müsste man diverse Umkonnektierungen (ggf. auch hardwaremäßig) durchführen, die im Zweifel einen Zeitrahmen von Tagen haben... :-)

Aber was Refferer-Logs sind verstehe ich jetzt gar nicht mehr. Ich dachte das wären die "normalen" Apache-Logfiles?!

Der Referrer ist "die Seite, auf der der Link zur aktuellen Seite stand" (genauer: "die Ressource, von der aus zur aktuellen Ressource referenziert wird" - bei Bildern also z.B. die Seite, auf der sie stehen). Apache-Logfiles sind so konfigurierbar, dass der Referrer, welcher ja nur ein weiterer HTTP-Header ist, mit drin steht.

Was hat das mit verschiedenen Benutzern zu tun?

Nichts :-) Aber wenn in meinem Logfile eine fremde Session-ID auftaucht (der Referrer ist ja sozusagen "die Vorgänger-Seite"), dann kann ich sie lesen und ggf. benutzen.

Meine eigenen Refferer bringen mir da ja nichts!

Es sind nicht "Deine" Referrer, sondern die des Users. In _meinem_ Logfile taucht die Seite auf, auf der _Du_ warst, _bevor_ Du zu mir gelangt bist.

Cheatah

[Andreas]

Hallo!

Die Hälfte wird es nicht sein, sondern nur die absolute Ausnahme. Dennoch: Der User-Agent ist als Erkennungsindiz sinnvoll bei sowas wie einer Counter-Reloadsperre, wenn es nichts ausmacht, nicht wiedererkannt zu werden. Bei allem, was einen Login erfordert, möchte der User zu Recht nicht ständig seine Daten neu eingeben müssen - das ist nämlich evtl. auch wieder ein Sicherheitsrisiko, oder zumindest scheint es so.

off-topic: Counter reload-Sperre ist gut, wenn ich einen einfachen counter habe, der einfach hochzählt, wie soll ich da sowas wie user-agent einbuinden? Dann müßte ich ja die einzelnen Zugriffe zählen und dann user_agent und IP in eine txt oder DB schreiben, was zu sehr viel unnötigem Datenmüll führt., naja, ich könnte ja imme rienträge älter als eine Studne löschen, dann brauch ich noch den Zeitpunkt, oder wie meintest Du das mit der Reload-Sperre? Ist das was anderes als bei online_Abstimmungen, wo man wenn einmal gewählt nicht mehr mitmachen(manipulieren) kann? Oder macht man sowas besser mit Cookies? Das wäre aber leicht zu überwinden.

denn komischerweise hatten alle Leute dieselbe REMOTE_ADRESS, und das war die des weiterleitenden Providers!

Das ist dann aber ein Problem, dass mit dem Webspace zusammenhängt, und ergo lösbar ist: spätestens durch einen Providerwechsel. Sowas musst Du nur einmalig sicherstellen, und brauchst es somit bei einem sicherheitsrelevanten Algorithmus nicht weiter zu beachten. Wichtig ist, was von Clientseite aus auf welche Weise zu Dir getragen wird.

Naja, aber ich
habe gerade mal in meinen eigenen "Versuchs-Logs" geguckt, und zwar habe ich mal zum rumprobieren auf einer Seite Vor jede Seite einen eigenen Log-mechanismus gehängt, der mir alle Daten "die ich kriegen kann" in eine MySQL Tabelle loggt, schon sortiert. Außerdem verpasse ich jedem auf der Seite eine PHPSESSID, die über Links weitergegeben wird. Die wird mitgeloggt, so kann ich sehr schön einzelne User über die Seite verfolgen(wirklich nur mal zum probieren :-)) ABER:
Ich habe festgestellt, das Leute mit gleicher IP Adresse während eines Besuches verschiedene IP-Adressen hatten!!! Hier mal ein Auszug durch folgende SQL-Abfrage:

SELECT
   IP,PHPSESSID,changed
  FROM h\_log
  GROUP BY IP
  ORDER BY changed DESC

Ändern  Löschen  217.5.97.131 1d2fd8f4d1c0c92cb801fdb359e951da 20020517093050
Ändern  Löschen  217.5.97.133 1d2fd8f4d1c0c92cb801fdb359e951da 20020517093036
Ändern  Löschen  217.5.97.129 1d2fd8f4d1c0c92cb801fdb359e951da 20020517093010
Ändern  Löschen  217.5.97.134 1d2fd8f4d1c0c92cb801fdb359e951da 20020517092948

Ändern  Löschen  195.93.73.7 3090408140be3b7bfeaf6fb601ecd3c8 20020501142455
Ändern  Löschen  195.93.73.10 3090408140be3b7bfeaf6fb601ecd3c8 20020501142333
Ändern  Löschen  195.93.72.7 3090408140be3b7bfeaf6fb601ecd3c8 20020501142144

Ändern  Löschen  195.93.64.7 f77b8f7650d56e21a9d49a275a11a726 20020428112828
Ändern  Löschen  195.93.64.11 f77b8f7650d56e21a9d49a275a11a726 20020428112440
Ändern  Löschen  195.93.65.10 f77b8f7650d56e21a9d49a275a11a726 20020428112323
Ändern  Löschen  195.93.65.7 f77b8f7650d56e21a9d49a275a11a726 20020428112229
Ändern  Löschen  195.93.66.8 f77b8f7650d56e21a9d49a275a11a726 20020428111650

Das war auf den ersten Blick erstmal alles, wobei dei Abfrage nicht wirklich gut ist, aber es sollte wenigstens ein Anhaltspunkt sein.
Das Problem an der Sache ist jetzt folgendes:
Auf dieser Seite zum Beispiel geht es darum, dass die User eine Objektbeschreibung ener Immobilie in zig Formularfelder eingeben müssen. Das dauert meist ein wenig, daher wird die Internetverbindung meist getrennt. Und normalerweise wählt man sich dann beim abschicken mit einer anderen IP an, die SessionID ist aber noch dieselbe, solange man nicht zu lange gewartet hat. Wenn ich jetzt nach der IP prüfe, wäre es vorbei - also alle die letzte haleb Stunde eingegebenen Daten sind unwiederruflich weg, das würde mich dazu veranlassen nie wieder auf diese Seite zu gehen, sondern zur Konkurrenz! Wenn ich mir das so anschaue, könnte ich in dieen Fällen ja (wohl zufällig, oder?) jedesmal die 2 beiden ersten Ziffern der IP behalten, also könnte ich die hja verwenden, aber das ist auf der einen Seite nicht mehr so sicher(aber besser als nix) aber auf der anderen Seite befürchte ich, das man z.B. bei t-online auf einmal eine gänzlich andere IP bekommt, oder? Was könnte man hie machen? Oder viellciht für diese eine Seite diesen Schutz aushebeln? Damit hätte ich aber ien Sicherheitsloch geschaffen. Was hääte ich noch für Optionen?

Nochmal kurz zur Fäkschungssicherheit, ich denke man kann ALLES was man dem Server schickt beeinflussen, wenn man sich da entsprechend auskennt. Mit der IP ist zwar erstmal dumm wenn man die eigene "ändert", denn dann kommen die Antworten woanders an, oder?

Ja, so in etwa.

Gibt es tatsächlich keine Möglichkeit, da irgendeinen bösen proxy oder was weiß ich zwischenzuhängen,

Klar, wenn dieser die IP des Users hat, als der man sich einloggen möchte - und das ist hinreichend unwahrscheinlich.

Das ist genau so wagrscheinlich wie ich an eine PHPSESSID komme, oder? Die wird doch auch überall mitgeloggt, genau wie der referer, oder?

Innerhalb des Session-Timeouts müsste man diverse Umkonnektierungen (ggf. auch hardwaremäßig) durchführen, die im Zweifel einen Zeitrahmen von Tagen haben... :-)
Naja... vielleicht dann doch nicht so einfach :-)

Apache-Logfiles sind so konfigurierbar, dass der Referrer, welcher ja nur ein weiterer HTTP-Header ist, mit drin steht.

Also doch, ich dachte schon das wäre ganz was anderes :-)

Es sind nicht "Deine" Referrer, sondern die des Users. In _meinem_ Logfile taucht die Seite auf, auf der _Du_ warst, _bevor_ Du zu mir gelangt bist.

Du meinst mit _meinen_ also die _meiner Homepage_, OK. Jetzt ist alles klar! Was Refferer sind ist mit bewußt!

Grüße
Andreas

[Andreas]

Also der Abschnitt mit meinem Logging-mechanismus ist wirklich etwas sehr fehlerbehaftet, heir eine überarbeitete Verion, sorry dafür:

Naja, aber ich habe gerade mal in meinen eigenen "Versuchs-Logs" nachgeschaut, und zwar habe ich mal zum rumprobieren vor jeder Seite einer Homepage einen eigenen Logging-Mechanismus gehängt, der mir alle Daten "die ich kriegen kann" in eine MySQL Tabelle loggt. Außerdem verpasse ich jedem Besucher auf der Homepage eine PHPSESSID, die über Links weitergegeben wird. Die wird mitgeloggt, und so kann ich sehr schön einzelne User über die Seite verfolgen(wirklich nur mal zum probieren :-))

ABER:
Ich habe festgestellt, das Leute mit gleicher _PHPSESSID_ während eines Besuches verschiedene IP-Adressen hatten!!!

Sorry nochmal!

Grüße
Andreas

[Michael Schröpl]

Hi,

Ich habe festgestellt, das Leute mit gleicher _PHPSESSID_ während
eines Besuches verschiedene IP-Adressen hatten!!!

ja - das kann passieren.
Die IP-Adresse kann innerhalb einer Dialogsitzung wechseln.

Viele Grüße
      Michael

[Michael Schröpl]

Hallo Cheatah,

denn komischerweise hatten alle Leute dieselbe REMOTE_ADRESS,
und das war die des weiterleitenden Providers!
Das ist dann aber ein Problem, dass mit dem Webspace zusammenhängt,

nicht unbedingt.

Wenn die Kommunikation über einen Netzknoten läuft, der eine
Adreßübersetzung macht, dann passieren solche Dinge.
Das _kann_ natürlich ein Netzknoten sein, der innerhalb des
Provider-Netzes liegt - aber genauso gut einer, der auf der
Seite des Besuchers liegt.

Es gibt Firmennetze, bei denen die Betreiber grundsätzlich keine
internen IP-Adressen nach außen sichtbar machen wollen. Alles, was
and Kommunikation heraus geht, durchläuft eine Adreßübersetzung -
in einem Proxy-Server, einer Firewall oder was auch immer.

Als Webspace-Betreiber würdest Du immer nur die IP-Adresse nach
der Übersetzung sehen - die Original-Adresse bleibt Dir verborgen,
eine Unterscheidung zwischen den Clients auf dem Server ist nicht
durch die IP-Adresse möglich.

Das kann ich zwar verhindern, aber kann sowas nicht auch
zwichen durch passieren, ohne dass ich Einfluß darauf habe?

Ja, das kann passieren - aus Firmennetzen heraus, beispielsweise.
Und es kann sehr gut sein, daß der Besucher das nicht selbst weiß

• sein Firewall-Administrator wüßte es vielleicht ...

Viele Grüße
      Michael

[Michael Schröpl]

Hi Cheatah,

REMOTE_PORT Da weiß ich nicht, ob der immer gleich bleibt,
wie ist das, wonach werden die Ports aufgeteilt?
Weiß ich ehrlich gesagt nicht.

Ergänzung (ohne Schusswaffen ;-):

Der Remote Port kann gleich bleiben oder sich ändern, das ist nicht
so ohne weiteres vorhersehbar.
Wenn zwischen Client und Server eine Kommunikationsform läuft, welche
den Remote-Port für mehrere Requests nutzen kann (persistente Verbin-dung; Apache: "KeepAlive"), dann kann der Port eine Weile lang gleich
bleiben; andernfalls wechselt er ständig (und es fällt zusätzlicher
TCP/IP-Overhead für den ständigen neuen Verbindungsaufbau an - diesen
zu vermeiden ist die Idee der persistenten Verbindungen).
Du kannst mit einen TCP-Dump eine Reihe von Requests tracen und die
Verwendung der einzelnen Port-Nummern sehr schön beobachten.

Persistente Verbindungen bringen etwas in Sachen Performance und
Bandbreiteneinsparung; das Problem ist, daß _alle_ Player auf dem
Weg das verstehen müssen.
Ich hatte mit einigen alten Proxy-Servern derartige Probleme, daß
ich das wieder abschalten mußte, weil diese Proxies nicht zur Dis-
position standen.

Viele Grüße
      Michael

[Andreas]

Hi Michael!

Aber was sind denn Deiner Meinung nach 100%ig Sicher Erkennungsmerkmale eines Clients?

IP? nicht
USER AGENT? nicht
Browsereinstellungen? nicht

Die Sachen sind alle irgendwo veränderbar, oder? Was gibt es eindeutiges? Nur cookies? Aber das doofe an Cookies ist die bei den Client so unsicher sind, oder?

Wie kann ich einen User definitiv wiedererkennen?

Viele Grüße
Andreas

[Michael Schröpl]

Hi,

Aber was sind denn Deiner Meinung nach 100%ig
Sicher Erkennungsmerkmale eines Clients?

habe ich irgendwo behauptet, es gäbe solche?

Die Sachen sind alle irgendwo veränderbar, oder?
Was gibt es eindeutiges? Nur cookies?

Ein Cookie ist nur ein Container.

Die Wiedererkennung muß aber basierend auf dem Inhalt
des Containers funktionieren.

Aber das doofe an Cookies ist die bei den Client
so unsicher sind, oder?

Diesen Satz habe ich weder syntaktisch noch semantisch
verstanden.

Wie kann ich einen User definitiv wiedererkennen?

"definitiv" - überhaupt nicht.

Woher willst Du wissen, ob nicht jemand anderer mich
gerade mit geladener Waffe von meiner Tastatur ver-trieben hat?

Viele Grüße
      Michael

[Sven Rautenberg]

Moin!

Ich hänge mich mal hier an (hab die nachfolgenden Postings wohl gelesen, nehme vielleicht auch versteckt darauf Bezug), hier scheint der passendste Platz dazu.

Eine Frage zu htaccess:
Die Passwörter werden auf dem Server ja verschlüsselt gespeichert. Wie funktioniert das dann bei der Eingabe, wird das was in das Fenster eingegeben wird direkt als username:crypt(passwort) im Arbeitspeicher abgelegt, oder im Klartext, und auch im Klartext übertragen, wenn man kein SSL benutzt?

Wie die Paßwörter auf dem Server gespeichert werden, ist primär uninteressant. Interessant ist: Wie kommen die Paßwörter vom Client zum Server. Und das läßt sich leicht beantworten:
AuthType Basic: Unverschlüsselt (!!!)
AuthType Digest: Verschlüsselt durch ein Challenge-Response-Verfahren. Die eigentliche HTML-Seite wird aber trotzdem unverschlüsselt ausgeliefert.

Bei SSL wird die Verschlüsselung auf einer tieferen Ebene realisiert, also sind alle Datenübermittlungen deshalb verschlüsselt. Frag mich nicht, wie Proxys das hinkriegen (https erfordert andere Proxys als normales http, und diese Proxys dürfen auch nichts speichern).

Und noch eine Frage wegen das anderen postings: Du sagst ein Problem ist wenn die SessionID in den Log-Files irgendwelcher Proxies... stehen, korrekt? Aber die Session wird doch rel schnell wieder gelöscht, wenn nicht mehr benötigt, das müßte also sehr zeitnah passieren, oder?

Wie lange ist die Session denn noch gültig, nachdem sie irgendwo in ein anderes Logfile geschrieben wurde? Das ist doch das Problem. Wenn jemand ein Webmail-Interface mit Sessions geschrieben hat, und ein Benutzer kriegt eine HTML-Mail mit Bildlink, der ein Bild auf dem Angreiferserver verlinkt, dann taucht dort der Referrer auf und liefert möglicherweise die Session-ID mit.

Wenn weiterhin anzunehmen ist, daß der User noch etwas mit Maillesen beschäftigt ist, ist jetzt genügend Zeit, die Sessiondaten zu übernehmen und als angemeldete User-Kopie ebenfalls in der Post zu stöbern.

Man kann, sofern die Implementierung des Mechanismus absolut mangelhaft ist, sogar das Paßwort ändern. Nämlich dann, wenn dem angemeldeten Benutzer einfach durch Angabe des neuen Paßwortes gestattet wird, es zu ändern, aber nicht mehr nach dem alten Paßwort gefragt wird. Schwups - der Mailaccount gehört dem Angreifer.

Erst wenn sich der reguläre Benutzer abmeldet und der Server die Session für ungültig erklärt (und daher keine weiteren Seiten für diese Session ausliefert), hat der Angreifer ebenfalls keinen Zugriff mehr. Aus genau diesem Grunde erzählen alle Webmail-Anbieter wie GMX oder web.de ihren Benutzern immer, wie wichtig es ist, daß man sich nach der Benutzung abmeldet und ordentlich ausloggt. Andernfalls würde die Session weiterhin bestehen und bis zum Timeout für Angreifer offen sein (sofern diese Anbieter wirklich so schlechte Interfaces haben, wie hier beschrieben - ich denke, das ist nicht der Fall).

Und wenn ich SSL verwende, wird dieses Risiko dann ausgeschaltet? Was steht dann  in den Refers? Der Proxy... muß aber doch irgendwie wissemn, wohin er weiterlieten soll, un dwenn der das weiß kann das doch auch geloggt werden, oder?

Die Brücke zwischen https und http wird AFAIK nicht geschlagen. Wenn du auf einer https-Seite einem Link folgst, kriegt die verlinkte http-Seite keinen Referrer übermittelt. Natürlich kriegt der jeweilige https-Server alle Referrer, die lokal auf dem Server bezogen sind - serverübergreifend wird IMHO nichts übermittelt.

Um das alles noch etwas sicherer zu machen, könnte ich ja evtl den kpl. HTTP_USER_AGENT verwenden. Ich hab mal in der phpinfo() geguckt, was wir da so alles schönes haben, in Frage kämen meiner Meinung:
HTTP_USER_AGENT - sehr verscheiden - gut geeignet, oder?

Der ist einigermaßen konstant bei der Mehrzahl der Benutzer. Und vor allem ist nicht zu erwarten, daß er sich zwischendrin ändert - jedenfalls nicht bei jedem Request.

HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?

Die Länge ist ja nicht unbedingt entscheidend. Die Frage ist, was du mit der Info machst. :)

REMOTE_ADDR - auch gut, aber was ist mit Proxys? Kann es nicht vorkommen, das die Adresse während des Besuches wechselt? ich meine jetzt nicht dyn IP-Vergabe, da ist die session eh zu Ende, oder? Wie ist das mit der IP?

Die Adresse kann sich während einer Session ändern - das ist IMO sehr häufig, zumindest zu häufig, um darauf eine zusätzliche Sicherung aufzubauen.

REMOTE_PORT Da weiß ich nicht, ob der immer gleich bleibt, wie ist das, wonach werden die Ports aufgeteilt?

Der Port ändert sich potentiell bei jedem Request, ist also völlig ungeeignet.

Überlege nochmal die Aufgabenstellung: Wie kann man serverseitig verhindern, daß andere User einfach die Session übernehmen bzw. mitsurfen?

Wenn der Browser vom Server einfach nur eine beliebige Nummer (Session ID) bekommt und diese Nummer immer wieder mitsendet, wenn er was vom Server will, dann kann ein Angreifer versuchen, die Nummer zu raten (und bei gutbesuchten Servern mit mehreren hunderttausend Sessions gleichzeitig ist die Chance dazu natürlich sehr gut).

Wenn der Server aber ein relativ eindeutiges Merkmal des Browsers mit zur Identifikation heranzieht (also z.B. den User-Agent), dann muß der Angreifer schon zwei Dinge richtig wissen: Erstens die Session ID, und zweitens den exakten User-Agent.

Genau das gleiche liegt vor, wenn per .htaccess vom Browser bei jedem Request Username und Paßwort gesendet werden - auch das muß der Angreifer raten.

Man kann natürlich argumentieren, daß keine der Browserangaben wirklich konstant ist, die Username/Passwort-Kombination hingegen schon. Was wäre die schlimmste Konsequenz? Beim Surfen wird sich der User im ersten Fall zwischendrin (nämlich wenn sich der User-Agent irgendwie ändert) nochmal neu anmelden müssen, was ihm durch eine erklärende Fehlermeldung ja einfach erklärt werden könnte.

Es reicht ja immer zu wissen, ob sich eher die Session beenden würde, als das sich z.B. der Port ändert. Weißt Du wie das ist? OK, von diesen Daten speichere ich dann eine bestimmte Kombination in der Session und das prüfe ich jedesmal, oder? Hat es Sinn, das noch mit MD5() zu verschlüsseln?

Auf dem Server die Info verschlüsseln macht nicht unbedingt viel Sinn, wenn du dem Server vertraust. Die Info über den regulären User-Agent der Session ist flüchtig, kann beim nächsten Anmeldevorgang schon wieder ganz anders aussehen. Außerdem ist es ein zusätzliches Merkmal zur Sicherung der Session, kein authentifizierendes.

Ein Paßwort mit MD5 verschlüsselt auf dem Server abzulegen macht mehr Sinn. Paßwörter werden in der Regel (leider) für eine lange Zeit benutzt, man sollte also in jedem Fall verhindern, daß für den unwahrscheinlichen Fall des Einbruchs in den Server gleich die Paßwörter im Klartext vorliegen und den Einbrechern direkt in die Hände fallen. Allerdings sind Mechanismen wie crypt() nicht mehr wirklich sicher - mit genügend Rechenpower sind solche Paßwörter in recht kurzer Zeit geknackt (wobei anzumerken ist, daß dabei nicht das Originalpaßwort wiederentstehen muß, sondern ein x-beliebiger Wert gefunden werden kann, der ebenfalls den gleichen crypt-Wert ergibt).

- Sven Rautenberg

[Andreas]

Hi!

Ich hänge mich mal hier an (hab die nachfolgenden Postings wohl gelesen, nehme vielleicht auch versteckt darauf Bezug), hier scheint der passendste Platz dazu.

war aber gefährlich, hätte ich fast überlesen, und das wäre wirklich schade gewesen :-)

Wie lange ist die Session denn noch gültig, nachdem sie irgendwo in ein anderes Logfile geschrieben wurde? Das ist doch das Problem. Wenn jemand ein Webmail-Interface mit Sessions geschrieben hat, und ein Benutzer kriegt eine HTML-Mail mit Bildlink, der ein Bild auf dem Angreiferserver verlinkt, dann taucht dort der Referrer auf und liefert möglicherweise die Session-ID mit.

Oh weh! Aber das kann dochnicht wirklich sein oder? Warum sollte der Link die SessionID des eigeloggten users mitliefern? Außerdem ist das ja dann großer Zufall, vielleicht könnte man dann mal bei nem Freund "Einbrechen", das ist lustig, bringt aber nicht viel ;-)

HTTP_USER_AGENT - sehr verscheiden - gut geeignet, oder?
Der ist einigermaßen konstant bei der Mehrzahl der Benutzer. Und vor allem ist nicht zu erwarten, daß er sich zwischendrin ändert - jedenfalls nicht bei jedem Request.

Aber das hörte sich gerade bei Cheatah etwas anders an, ich zitiere(http://forum.de.selfhtml.org/?m=74151&t=13365):

Warum denn nicht den HTTP_USER_AGENT???

der Header kann beliebig verändert, also auch z.B. von einem Proxy mit dem Timestamp versehen werden. In dem Fall würde die Erkennung versagen.

Was sagst Du dazu?
Das in einer SessionID mehrer IPs vorkommen können, habe ich da "bewiesen"(am besten liest Du vorher die Korrektue :-):http://forum.de.selfhtml.org/?m=74285&t=13365):
http://forum.de.selfhtml.org/?m=74280&t=13365

HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?
Die Länge ist ja nicht unbedingt entscheidend. Die Frage ist, was du mit der Info machst. :)

Ich meinte auch nur wenn ich das speichere, aber das muß man ja nicht lange speichern, hatte ich nicht daran gedacht. Aber der Vorteil hier wäre wohl, das das von keinen proxies... zwischenruch verändert wird, oder? Ist nur die Frage, wie berechtigt Cheatah´s Kritik daran war, das es davon nur sehr wenige Kombinationsmöglickeiten gibt. Wie ist das Wohl im Verhältnis zum User_Agent? Ich denke auch da machen bestimmt 50-100 Verschiedene 80-90% der Besucher aus, oder? Also keine besonders große Herausforderung an einen Hobby-Cracker, oder?

REMOTE_ADDR - auch gut, aber was ist mit Proxys? Kann es nicht vorkommen, das die Adresse während des Besuches wechselt? ich meine jetzt nicht dyn IP-Vergabe, da ist die session eh zu Ende, oder? Wie ist das mit der IP?
Die Adresse kann sich während einer Session ändern - das ist IMO sehr häufig, zumindest zu häufig, um darauf eine zusätzliche Sicherung aufzubauen.

Hat wohl auch keinen Sinn, wenigstens die ersten beiden Zahlen der IP auszuwerten, das hätte in meinem obigen Beispiel funktioniert, wird aber wohl bei T-Online auch anders sein können, das man von ner 80... auf ne 195... kommt, in einer Session, oder?

Überlege nochmal die Aufgabenstellung: Wie kann man serverseitig verhindern, daß andere User einfach die Session übernehmen bzw. mitsurfen?

Man muß eine Möglichkeit haben, Daten die der Client _immer gleich_ mitsendet, und die möglichst differenziert sind auszulesen.

Wenn der Server aber ein relativ eindeutiges Merkmal des Browsers mit zur Identifikation heranzieht (also z.B. den User-Agent), dann muß der Angreifer schon zwei Dinge richtig wissen: Erstens die Session ID, und zweitens den exakten User-Agent.

Aber nur mal angenommen ein Angreifer bekommt die SessionID aus dem Referer-Eintrag in irgendwelchen log-Files, da steht der Agent doch direkt daneben, oder?

Genau das gleiche liegt vor, wenn per .htaccess vom Browser bei jedem Request Username und Paßwort gesendet werden - auch das muß der Angreifer raten.

Aber mir ginge es mal um eine Lösung ohne .htaccess, das diese Lösung optimal ist ist mir bewußt, aber man muß doch wenigsten einigermaßen mit anderen Mitteln ähnliche Sicherheit erreichen können, oder?

Man kann natürlich argumentieren, daß keine der Browserangaben wirklich konstant ist, die Username/Passwort-Kombination hingegen schon. Was wäre die schlimmste Konsequenz? Beim Surfen wird sich der User im ersten Fall zwischendrin (nämlich wenn sich der User-Agent irgendwie ändert) nochmal neu anmelden müssen, was ihm durch eine erklärende Fehlermeldung ja einfach erklärt werden könnte.

Aber wenn der sich jedesmal duch den Timestamp eines Proxy ändert? das wäre schon schwierig dem User zu erklären (zumindest automatsich)!
Man braucht eindeutige Angaben des Browser. Was ist denn mit solchen Sachen wie akzeptiert Cookies, Javascript... was es da so alles gibt, das wird sich doch auch nicht über die Session ändern, oder? Wenn man daraus irgendwie was strickt? Nur leider gibt es ja immer nur 2 Möglichkeit bei sowas, an/aus, also auch nicht wirklich sehr verschieden, was? Was gibt es denn evtl, was sehr verschieden ist(viele Möglichkeiten), aber auf alle Fällte immer konstant an den Server gesendet wird? Die IP wäre so genial, aber fällte denke ich aus besagten Gründen raus.

Ein Paßwort mit MD5 verschlüsselt auf dem Server abzulegen macht mehr Sinn.

Das mache ich sowieso! War das mit dem Hash aus Username und Passwort und as ganze verschlüsselt speichern! Alles drum herum mit SSL.

Allerdings sind Mechanismen wie crypt() nicht mehr wirklich sicher - mit genügend Rechenpower sind solche Paßwörter in recht kurzer Zeit geknackt (wobei anzumerken ist, daß dabei nicht das Originalpaßwort wiederentstehen muß, sondern ein x-beliebiger Wert gefunden werden kann, der ebenfalls den gleichen crypt-Wert ergibt).

Daher verwende ich ja md5() - da gibt es nur eine Möglichkeit ;-)
Aber crypt verstehe ich selbst nicht richtig, wenn ich ein Passwort mit crypt() verschlüssele, bekomme ich immer einen anderen String?!?!? Wieso überhaupt?
Und was ich dann noch weniger verstehe, wenn ich vergleiche:

if($crypt_pw==crypt(klartext_pw)

MUSS da doch eine Ungleichheit rauskommen, oder?  Die Wahrscheinlichkeit das das wieder gleich verschlüsselt ist doch fast = 0, oder? Aber es funktioniert trotzdem, wieso?

Und anders herum ist das ja schlimm, wenn auch andere Wörter den gleichen crypt() String ergeben, ist das dann tatsächlich der gleiche String, oder auch noch ein anderer der irgendwie passt(so wie oben!!!) Aber das wäre ja richtig schlimm!  Weißt Du wie das Verhältnis ist, echtes_Passwort:passendes_anderes_Passwort?

Vielen Dank für dein hilfreiche Antwort!

Viele Grüße
Andreas

• Sven Rautenberg

[Sven Rautenberg]

Moin!

Oh weh! Aber das kann dochnicht wirklich sein oder? Warum sollte der Link die SessionID des eigeloggten users mitliefern? Außerdem ist das ja dann großer Zufall, vielleicht könnte man dann mal bei nem Freund "Einbrechen", das ist lustig, bringt aber nicht viel ;-)

Wenn die Session-ID mit GET übermittelt wird, weil der User keine Cookies akzeptiert, dann gelangt die Session-ID über den Referrer auch woandershin.

Wenn Cookies verwendet werden, natürlich nicht. Insofern ist die Methode mit Cookies natürlich besser, weil der Browser diese Daten im Cookie wirklich nur an den entsprechenden Server zurücksendet (oder wahlweise an Server dieser Second-Level-Domain), aber sicher ist es dadurch natürlich noch lange nicht. Nur die Session-ID im Cookie kann ebenfalls geraten werden. Da sollte dann doch lieber der Timestamp der Anmeldung mit reingeraten und verschlüsselt werden. Den Timestamp kann dann nur der Server generieren, und nur wer sich ordentlich angemeldet hat, kann arbeiten.

Wenn die Sicherheit es erfordert, muß man eben Cookies zur Pflicht machen.

Aber das hörte sich gerade bei Cheatah etwas anders an, ich zitiere(http://forum.de.selfhtml.org/?m=74151&t=13365):

Warum denn nicht den HTTP_USER_AGENT???

der Header kann beliebig verändert, also auch z.B. von einem Proxy mit dem Timestamp versehen werden. In dem Fall würde die Erkennung versagen.

Was sagst Du dazu?

Ja, Proxys könnten da was reinfummeln. Aber wie häufig und wahrscheinlich ist das? Und was passiert, wenn es tatsächlich gemacht wird? Wenn man die Möglichkeit voraussieht und sich entsprechend darauf einstellt, dann ist das zwar auch ein Problem, aber nur ein relativ kleines für eine sehr begrenzte Zahl von Benutzern. Und wenn man das Problem durch Umgehen des Proxys abstellen kann - ok. Wer das nicht kann - Pech. Lieber gewisse Mindestforderungen stellen, als unsicher werden, oder?

Das in einer SessionID mehrer IPs vorkommen können, habe ich da "bewiesen"(am besten liest Du vorher die Korrektue :-):http://forum.de.selfhtml.org/?m=74285&t=13365):
http://forum.de.selfhtml.org/?m=74280&t=13365

HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?
Die Länge ist ja nicht unbedingt entscheidend. Die Frage ist, was du mit der Info machst. :)
Ich meinte auch nur wenn ich das speichere, aber das muß man ja nicht lange speichern, hatte ich nicht daran gedacht. Aber der Vorteil hier wäre wohl, das das von keinen proxies... zwischenruch verändert wird, oder? Ist nur die Frage, wie berechtigt Cheatah´s Kritik daran war, das es davon nur sehr wenige Kombinationsmöglickeiten gibt. Wie ist das Wohl im Verhältnis zum User_Agent? Ich denke auch da machen bestimmt 50-100 Verschiedene 80-90% der Besucher aus, oder? Also keine besonders große Herausforderung an einen Hobby-Cracker, oder?

Eben, die meisten Browser akzeptieren nun mal text/html, image/gif, image/jpg und */*. Nur sehr selten tragen sich hier Plugins ein, die dann ebenso auftauchen - dazu wird diese Browserangabe viel zu selten ausgewertet. Ich habe beispielsweise noch von keinem Server gehört, der dem Browser wahlweise GIF, JPG oder PNG liefert, je nach Wunsch. Das wäre viel zuviel Aufwand für den Ersteller (der sich entweder für GIF entscheidet, weil er transparenz braucht oder Schriften hat, oder für JPG, weil Fotos vorliegen). Es lohnt also kaum, sich hieran zu orientieren, die Angaben sind zu ähnlich.

REMOTE_ADDR - auch gut, aber was ist mit Proxys? Kann es nicht vorkommen, das die Adresse während des Besuches wechselt? ich meine jetzt nicht dyn IP-Vergabe, da ist die session eh zu Ende, oder? Wie ist das mit der IP?
Die Adresse kann sich während einer Session ändern - das ist IMO sehr häufig, zumindest zu häufig, um darauf eine zusätzliche Sicherung aufzubauen.
Hat wohl auch keinen Sinn, wenigstens die ersten beiden Zahlen der IP auszuwerten, das hätte in meinem obigen Beispiel funktioniert, wird aber wohl bei T-Online auch anders sein können, das man von ner 80... auf ne 195... kommt, in einer Session, oder?

Du hast dann immer noch einen riesigen Bereich des Internets, aus dem gleichzeitig Benutzer und Angreifer kommen könnten. 62.0.0.0/8 ist beispielsweise der Beginn von IP-Adressen in Israel, Griechenland, der Schweiz... ich hab nurmal kurz angetestet, was ripe.net dazu sagte. Deutschland ist auch vertreten.

Letztendlich ist eine IP-Adresse leider kein eindeutiges Kennzeichen eines Benutzers. Ein Benutzer kann mehrere IPs benutzen, und mehrere Benutzer eine einzige.

Überlege nochmal die Aufgabenstellung: Wie kann man serverseitig verhindern, daß andere User einfach die Session übernehmen bzw. mitsurfen?
Man muß eine Möglichkeit haben, Daten die der Client _immer gleich_ mitsendet, und die möglichst differenziert sind auszulesen.

Wenn der Server aber ein relativ eindeutiges Merkmal des Browsers mit zur Identifikation heranzieht (also z.B. den User-Agent), dann muß der Angreifer schon zwei Dinge richtig wissen: Erstens die Session ID, und zweitens den exakten User-Agent.
Aber nur mal angenommen ein Angreifer bekommt die SessionID aus dem Referer-Eintrag in irgendwelchen log-Files, da steht der Agent doch direkt daneben, oder?

Bingo, daran hatte ich irgendwie nicht gedacht. Allerdings weiß das der Angreifer natürlich nicht, und ein schlaues System wird den Einloggversuch mit falschen Daten bei gleichzeitig aktiver Session mit richtigen Daten registrieren und evtl. Warnungen aussprechen oder die Session beenden und eine Neuanmeldung verlangen.

Naja, letztendlich stimmt in solch einem Fall was an der Sicherheit nicht, und diese obige Idee wäre ein Nachreparieren, wo vorher grundlegende Konstruktionsfehler gemacht wurden. Außerdem kann das wieder mal bei flexiblen Benutzern (z.B. zweiter Browser des gleichen Benutzers, URL per Copy&Paste übertragen -> User-Agent unterschiedlich) zu Fehlern führen, die nicht sein müssen.

Genau das gleiche liegt vor, wenn per .htaccess vom Browser bei jedem Request Username und Paßwort gesendet werden - auch das muß der Angreifer raten.
Aber mir ginge es mal um eine Lösung ohne .htaccess, das diese Lösung optimal ist ist mir bewußt, aber man muß doch wenigsten einigermaßen mit anderen Mitteln ähnliche Sicherheit erreichen können, oder?

Anscheinend nicht so einfach. Im Prinzip wirklich nur mit Cookies. Der Cookie wird, genau wie die Useranmeldung bei .htaccess, ausschließlich an den jeweiligen Webserver gesendet, und zwar im HTTP-Request. Keine dieser Daten gelangen durch irgendwelche Datenlecks wie Referrer etc. an andere Webserver, da zum Glück entsprechende Sicherheitsvorschriften gemacht wurden. Das System kann nur kompromittiert werden, wenn der Angreifer die Kommunikation zwischen Benutzer und Server abhören kann.

Man braucht eindeutige Angaben des Browser. Was ist denn mit solchen Sachen wie akzeptiert Cookies, Javascript... was es da so alles gibt, das wird sich doch auch nicht über die Session ändern, oder? Wenn man daraus irgendwie was strickt? Nur leider gibt es ja immer nur 2 Möglichkeit bei sowas, an/aus, also auch nicht wirklich sehr verschieden, was? Was gibt es denn evtl, was sehr verschieden ist(viele Möglichkeiten), aber auf alle Fällte immer konstant an den Server gesendet wird? Die IP wäre so genial, aber fällte denke ich aus besagten Gründen raus.

Das ist alles nichts. Wie findest du raus, daß Javascript aktiv ist? Du läßt eine externe Javascript-Datei laden. Wie kriegst du diese Information eines vollkommen separaten Requests in die eigentliche Sessioninformation mit hinein? Wohl garnicht. Was, wenn der Benutzer beim Anmelden JS ausgeschaltet hat und es aus irgendwelchen Gründen zwischendurch einschaltet - oder umgekehrt? Eben...

Allerdings sind Mechanismen wie crypt() nicht mehr wirklich sicher - mit genügend Rechenpower sind solche Paßwörter in recht kurzer Zeit geknackt (wobei anzumerken ist, daß dabei nicht das Originalpaßwort wiederentstehen muß, sondern ein x-beliebiger Wert gefunden werden kann, der ebenfalls den gleichen crypt-Wert ergibt).
Daher verwende ich ja md5() - da gibt es nur eine Möglichkeit ;-)

Ich will dich ja nicht beunruhigen, aber bei md5 kommt doch immer ein String konstanter Länge heraus. Der ist zwar wesentlich länger, als der bei Crypt, aber er ist konstant. Folglich bietet er nur eine begrenzte Anzahl an verschiedenen Variantionen von Zeichen. Und entsprechend gibt es die Möglichkeit, daß zwei verschiedene zu verschlüsselnde Texte das gleiche MD5-Ergebnis haben. MD5 ist doch genauso eine Einweg-Crypto-Hash-Methode wie crypt(). Nur daß man wesentlich länger sucht.

Aber crypt verstehe ich selbst nicht richtig, wenn ich ein Passwort mit crypt() verschlüssele, bekomme ich immer einen anderen String?!?!? Wieso überhaupt?

Es wird zusätzlich zum zu verschlüsselnden Paßwort noch ein Salz-Wert hinzugefügt. Das sind die ersten beiden Zeichen des Ergebnisses. Wenn du ohne Salz-Angabe crypt() verwendest, werden zufällige Werte als Salz genommen (wahlweise auch immer derselbe Wert).

Und was ich dann noch weniger verstehe, wenn ich vergleiche:

if($crypt_pw==crypt(klartext_pw)

Du mußt eben dafür sorgen, daß das Salz identisch ist, indem du einfach das verschlüsselte Paßwort als Salzwert an crypt() mit übergibst. Crypt wird die ersten beiden Zeichen als Salz verwenden.

Sinn des Salzwertes ist es: Wenn unterschiedliche Salzwerte genommen werden, sehen gleiche Paßwörter verschlüsselt trotzdem unterschiedlich aus. Eine reine Maßnahme fürs Auge scheinbar.

Und anders herum ist das ja schlimm, wenn auch andere Wörter den gleichen crypt() String ergeben, ist das dann tatsächlich der gleiche String, oder auch noch ein anderer der irgendwie passt(so wie oben!!!) Aber das wäre ja richtig schlimm!  Weißt Du wie das Verhältnis ist, echtes_Passwort:passendes_anderes_Passwort?

Wenn crypt beispielsweise nur die ersten 8 Zeichen des Paßwortes verschlüsselt, sind logischerweise alle längeren Paßwörter mit dem nur 8 Zeichen langen Fragment identisch. "Kammerspiele" und "Kammerspaß" wären gleich.

Ebenso: Wenn crypt nur 8 Zeichen Ergebnis hat, und als Zeichenvorrat nur kleine und große Buchstaben auswirft, sowie die 10 Ziffern, dann gibts 62 verschiedene Zeichen. Insgesamt bei 8 Zeichen also 218.340.105.584.896 verschiedene Ergebnisse von crypt() (das Salz kennt man ja, wenn man das verschlüsselte Ergebnis hat, spielt also keine Rolle bei Angriffen).

Man kann sich aber vorstellen, daß es bei unbegrenzter Länge des Paßwortes ganz sicher unendlich viele Paßwörter gibt. Unendlich viele Inputvarianten werden auf 218.340.105.584.896 Outputvarianten gemappt - da gibt es Dopplungen im Ergebnis, ganz klar. Wie lange man dafür suchen muß, kann ich aber nicht sagen.

- Sven Rautenberg

[Andreas]

hi!

Wenn Cookies verwendet werden, natürlich nicht. Insofern ist die Methode mit Cookies natürlich besser, weil der Browser diese Daten im Cookie wirklich nur an den entsprechenden Server zurücksendet (oder wahlweise an Server dieser Second-Level-Domain), aber sicher ist es dadurch natürlich noch lange nicht. Nur die Session-ID im Cookie kann ebenfalls geraten werden. Da sollte dann doch lieber der Timestamp der Anmeldung mit reingeraten und verschlüsselt werden. Den Timestamp kann dann nur der Server generieren, und nur wer sich ordentlich angemeldet hat, kann arbeiten.

Wenn die Sicherheit es erfordert, muß man eben Cookies zur Pflicht machen.

OK, also cookies, aber nicht für die SesionID sondern vielleicht microtime() oder so ja? Auch hier wieder, sollteman das noch verschlüsseln?
Ach ja, und den Wert registriere ich in der Session und kann dann immer vergleichen, prima :-)
Aber bei der Flut an Trojanern und Würmern sind Cookies ja auch nicht mehr unbedingt das sicherste, naja.

Ja, Proxys könnten da was reinfummeln. Aber wie häufig und wahrscheinlich ist das? Und was passiert, wenn es tatsächlich gemacht wird? Wenn man die Möglichkeit voraussieht und sich entsprechend darauf einstellt, dann ist das zwar auch ein Problem, aber nur ein relativ kleines für eine sehr begrenzte Zahl von Benutzern. Und wenn man das Problem durch Umgehen des Proxys abstellen kann - ok. Wer das nicht kann - Pech. Lieber gewisse Mindestforderungen stellen, als unsicher werden, oder?

Aber das Problem kann nur bei Leuten auftreten, die selber bewußt Proxies verwenden? Ich meine es gibt ja acuh viele proxies in Firmen... und ich glaube alle AOL User hängen hinter Proxies, wenn ich mich recht erinnere! Also schon ein paar mehr Leute! Wobei damit nicht gesagt ist, das die proxies alle den Referer verändern, naja.

Eben, die meisten Browser akzeptieren nun mal text/html, image/gif, image/jpg und */*. Nur sehr selten tragen sich hier Plugins ein, die dann ebenso auftauchen - dazu wird diese Browserangabe viel zu selten ausgewertet. Ich habe beispielsweise noch von keinem Server gehört, der dem Browser wahlweise GIF, JPG oder PNG liefert, je nach Wunsch. Das wäre viel zuviel Aufwand für den Ersteller (der sich entweder für GIF entscheidet, weil er transparenz braucht oder Schriften hat, oder für JPG, weil Fotos vorliegen). Es lohnt also kaum, sich hieran zu orientieren, die Angaben sind zu ähnlich.

Aber gerade weil es so dumm wäre kommt da noch nicht mal ein schlauer Cracker drauf, und da das so lang ist kommt er auch mit probieren nicht sehr weit :-)))

Du hast dann immer noch einen riesigen Bereich des Internets, aus dem gleichzeitig Benutzer und Angreifer kommen könnten. 62.0.0.0/8 ist beispielsweise der Beginn von IP-Adressen in Israel, Griechenland, der Schweiz... ich hab nurmal kurz angetestet, was ripe.net dazu sagte. Deutschland ist auch vertreten.

Naja, hast Recht, aber was mich noch mehr stört ist die Tatsache, das es anders herum auch ahnungslose User die die Internet-Verbindung getrennt hatten rausschmeißen kann!

Aber nur mal angenommen ein Angreifer bekommt die SessionID aus dem Referer-Eintrag in irgendwelchen log-Files, da steht der Agent doch direkt daneben, oder?

Bingo, daran hatte ich irgendwie nicht gedacht. Allerdings weiß das der Angreifer natürlich nicht, und ein schlaues System wird den Einloggversuch mit falschen Daten bei gleichzeitig aktiver Session mit richtigen Daten registrieren und evtl. Warnungen aussprechen oder die Session beenden und eine Neuanmeldung verlangen.

Naja, letztendlich stimmt in solch einem Fall was an der Sicherheit nicht, und diese obige Idee wäre ein Nachreparieren, wo vorher grundlegende Konstruktionsfehler gemacht wurden. Außerdem kann das wieder mal bei flexiblen Benutzern (z.B. zweiter Browser des gleichen Benutzers, URL per Copy&Paste übertragen -> User-Agent unterschiedlich) zu Fehlern führen, die nicht sein müssen.

Ja, aber das könnte man ja grundsätzlich machen, wenn irgendwas nicht stimmt! Wenn der User sowas macht ist er selbst schuld, wenn er in einem sensiblen Bereich arbeitet. Da bringen ja noch nichtmal Cooies was, geschweige denn htaccess!!!

Anscheinend nicht so einfach. Im Prinzip wirklich nur mit Cookies. Der Cookie wird, genau wie die Useranmeldung bei .htaccess, ausschließlich an den jeweiligen Webserver gesendet, und zwar im HTTP-Request. Keine dieser Daten gelangen durch irgendwelche Datenlecks wie Referrer etc. an andere Webserver, da zum Glück entsprechende Sicherheitsvorschriften gemacht wurden. Das System kann nur kompromittiert werden, wenn der Angreifer die Kommunikation zwischen Benutzer und Server abhören kann.

Aber das hätte ja bei htaccess dasselbe Resultat, oder? Aber kann man das denn überhaupt abhören, wenn man per SSL verschlüsselt?

Das ist alles nichts. Wie findest du raus, daß Javascript aktiv ist? Du läßt eine externe Javascript-Datei laden. Wie kriegst du diese Information eines vollkommen separaten Requests in die eigentliche Sessioninformation mit hinein? Wohl garnicht. Was, wenn der Benutzer beim Anmelden JS ausgeschaltet hat und es aus irgendwelchen Gründen zwischendurch einschaltet - oder umgekehrt? Eben...

http://www.php.net/manual/de/function.get-browser.php
ich weiß, das ist nicht 100%ig, da kann man fälschen, das stimmt eh nicht... das hatten wir alles schon! Aber tatsache ist, das man diese Werte abfragen kann, und ich bin mir 100%ig sicher, das keiner auf dei Idee kommen wird, mal zwischendurch seine Einstellungen der Art zu verändern. Auf anderen Seiten vielleicht(glaube ich aber grundsätzlich nicht), aber die durchschnittlichen User der betroffenen Seite wissen wahrscheinlich noch nichtmal dass man das mache kann...
und das verändert sich _garantiert_ nicht bei irgendwelchen Proxies! Ein weiterer Vorteil, ich denke 90% der User haben Javascript & Co eingeschaltet, und wenn jetzt einer mit was für tools auch immer probiert auf die Seite mit bekannter Sesion ID und bekanntem Timestamp auf die Seite zuzugreifen, wird er scheitern, solange der User Javascript aktiviert hatte, denn solche "Sicherheits"-Software wird sowas wohl kaum mitsenden, oder?

Und was ich dann noch weniger verstehe, wenn ich vergleiche:

if($crypt_pw==crypt(klartext_pw)

Du mußt eben dafür sorgen, daß das Salz identisch ist, indem du einfach das verschlüsselte Paßwort als Salzwert an crypt() mit übergibst. Crypt wird die ersten beiden Zeichen als Salz verwenden.

Aber was mache ich bei der ursprünglichen Verschlüsselung? Ich könnte mir das nur mit dem Klartext Passort vorstellen, das habe ich sowohl wenn ich das erste mal verschlüsele und das speicher, und jedesmal wenn ich prüfe. Aber das als Parameter eine Funktion, die mir erstmalig ein Passwort verschlüsseln soll das eigentlichen Ergebnis anzugeben geht IMHO nicht, oder? Wie hattest Du das gemeint?

Man kann sich aber vorstellen, daß es bei unbegrenzter Länge des Paßwortes ganz sicher unendlich viele Paßwörter gibt. Unendlich viele Inputvarianten werden auf 218.340.105.584.896 Outputvarianten gemappt - da gibt es Dopplungen im Ergebnis, ganz klar. Wie lange man dafür suchen muß, kann ich aber nicht sagen.

Na das hört sich ja rosig an :-)

Grüße
Andreas

[Sven Rautenberg]

Moin!

Wenn die Sicherheit es erfordert, muß man eben Cookies zur Pflicht machen.

OK, also cookies, aber nicht für die SesionID sondern vielleicht microtime() oder so ja? Auch hier wieder, sollteman das noch verschlüsseln?

Cookies _auch_ für die Session-ID, aber eben nicht nur.

Die bisherigen Überlegungen haben ja wohl ergeben, daß Cookies recht privat sind. Niemand sonst kriegt unbeabsichtigt Kenntnis. Also im Prinzip genau identisch, wie eine Benutzeranmeldung.

Wenn man die Session-ID raten kann und so angemeldeter Benutzer wird, ist das schlecht. Deshalb muß der Server etwas mehr prüfen. Wenn er als Cookieinhalt zusätzlich noch den Zeitpunkt der Anmeldung speichert, und dieses ebenfalls in der Benutzerdatenbank (vielleicht auch in den Sessiondaten - ich habe da aber ein ganz kleinwenig Unbehagen bei, weil im Cookie die Session-ID ist, die den gespeicherten Zeitstempel enthält) , dann muß man schon mal zusätzlich auch noch den Anmeldezeitpunkt raten.

Wenn dann auch noch dieser Zeitstempel verschlüsselt wird, dann weiß man garnicht mehr, daß es ein Zeitstempel ist, und muß so richtig raten.

Wenn man dann das ganze noch weiter ausarbeitet, dann hat man im Prinzip eine längere Zeichenkette: 32 Zeichen Session-ID, und beispielsweise weitere 32 Zeichen verschlüsselter Timestamp, also 64 Zeichen. Was unterscheidet diese Zeichenkette nun von einer gewöhnlichen Session-ID? Eigentlich nicht mehr viel. Man kann genausogut 64 Zeichen lange Session-IDs generieren, die ein Angreifer ebenfalls irgendwie raten könnte - er muß ja einfach nur 64 korrekte Zeichen raten.

Und so sehen wir: Es ist vollkommen unmöglich, eine Session gegen Raten 100% abzusichern, man kann nur versuchen, den Rateaufwand hinreichend groß zu machen. Wenn man 1024 Zeichen raten muß, wird jeder Angreifer schlicht aufgeben. Sind bei 26 Buchstaben ja auch "nur" etwa 8,5*10^1448 verschiedene Möglichkeiten, also für jeden der ungefähr 6 Milliarden Erdenbürger exakt 1,4274374009915182902106399964072*10^1439 mögliche Sessions, wenn alle Menschen der Welt gleichzeitig angemeldet sind. Sollte grob gesagt ausreichen. ;)

Ich denke, die Diskussion über Session-IDs läßt sich schlicht so subsummieren: Unratbar, wenn sie hinreichend lang ist - sie sollte nur einfach niemandem bekannt gemacht werden. Das ist ein viel größeres Problem. Unverschlüsselte Kommunikation ist dann natürlich ziemlich schlecht - da muß man nicht raten, man lauscht einfach in die Kommunikation hinein und kriegt alles geliefert, was man benötigt. Da ist es dann auch relativ egal, ob Sessions oder Authentifizierung verwendet werden.

Das Problem besteht übrigens für jegliche Form der zusätzlichen Browsererkennung: Sie erhöht nur den Rateaufwand - wer erstmal spitzkriegt, daß er nur gewisse Bereiche des HTTP-Headers imitieren muß, wird defaultmäßig einfach zu einem identischen Browser, weil er alles kopiert, was der eigentliche Benutzer liefert. Hilft also nichts für die Sicherheit.

Und was ich dann noch weniger verstehe, wenn ich vergleiche:

if($crypt_pw==crypt(klartext_pw)

Du mußt eben dafür sorgen, daß das Salz identisch ist, indem du einfach das verschlüsselte Paßwort als Salzwert an crypt() mit übergibst. Crypt wird die ersten beiden Zeichen als Salz verwenden.

Aber was mache ich bei der ursprünglichen Verschlüsselung? Ich könnte mir das nur mit dem Klartext Passort vorstellen, das habe ich sowohl wenn ich das erste mal verschlüsele und das speicher, und jedesmal wenn ich prüfe. Aber das als Parameter eine Funktion, die mir erstmalig ein Passwort verschlüsseln soll das eigentlichen Ergebnis anzugeben geht IMHO nicht, oder? Wie hattest Du das gemeint?

Bei der ersten Verschlüsselung denkst du dir ein Salz aus. Oder nimmst einen festen oder zufälligen Wert. Ist vollkommen egal für die Verschlüsselung.

- Sven Rautenberg

[Andreas]

Hi!

Cookies _auch_ für die Session-ID, aber eben nicht nur.

Ich mache das dann mit Trans-SID, mit dem Fallback Mechanismus, falls Cookies nicht akzeptiert werden.

Die bisherigen Überlegungen haben ja wohl ergeben, daß Cookies recht privat sind. Niemand sonst kriegt unbeabsichtigt Kenntnis. Also im Prinzip genau identisch, wie eine Benutzeranmeldung.

Das bezweifele ich aber! Ich hatte unbeabsichtigt innerhalb von 2-3 Wochen 3 Trojaner und 5 Würmer auf meinem Computer - ich denke das geht vielen Leuten nicht anders! Und ich bin der Überzeugung, das SEHR viel mehr Leute(Kinder) in der Lage sind private PCs auszuspionieren, als irgendwie den Traffic mitzulauschen, der bei mir SSL-verschlüsselt ist. Und ich denke, das es komplizierter ist, eine Variable aus dem http-Request des Browsers zu erfahren, als einen Cookie zu finden! Den/die kopiert auf den eigenen Rechner und schon geht alles wunderbar! Aber wie ich aus dem Browser die immer mitgeschickte SessionID bekommen sollte, wüßte ich nicht.

Wenn man die Session-ID raten kann und so angemeldeter Benutzer wird, ist das schlecht. Deshalb muß der Server etwas mehr prüfen. Wenn er als Cookieinhalt zusätzlich noch den Zeitpunkt der Anmeldung speichert, und dieses ebenfalls in der Benutzerdatenbank (vielleicht auch in den Sessiondaten - ich habe da aber ein ganz kleinwenig Unbehagen bei, weil im Cookie die Session-ID ist, die den gespeicherten Zeitstempel enthält) , dann muß man schon mal zusätzlich auch noch den Anmeldezeitpunkt raten.

Aber was ist das für ein Unterschied ob in DB oder Session?  Wenn man den cookie hat ist es jawohl total egal wo das gespeichert ist! Ob man jetzt auf dem Server die Variable aus den Sessendaten ausliest, oder aus der Datenbank ist doch NULL Unterschied, oder? Nur das ich dann mit der DB enweder eine Session-Tabelle bräuchte, oder immer in der Benutzertabelle immer einen Timestamp überschreiben müßte - wobei ich hier natürlich prima prüfen könnte, ob der user nur einmal angemeldet ist, obwohl, das bringt ja nix wenn ich den Echten und den Angreifer nicht unterscheiden kann...
Aber erkläre mir Dein Unbehagen - kann ich nicht nachvollziehen?

Wenn dann auch noch dieser Zeitstempel verschlüsselt wird, dann weiß man garnicht mehr, daß es ein Zeitstempel ist, und muß so richtig raten.

Aber ich denke das ein Zeitstemptel sehr beliebt ist, daher bräuchte ich vielleicht noch etwas, eine Kombination aus Timestamp + User Agent, oder aus den get_browser() Sachen, oder? Das dann verschlüsselt sollte schwieriger nachvollziebar sein.

Wenn man dann das ganze noch weiter ausarbeitet, dann hat man im Prinzip eine längere Zeichenkette: 32 Zeichen Session-ID, und beispielsweise weitere 32 Zeichen verschlüsselter Timestamp, also 64 Zeichen. Was unterscheidet diese Zeichenkette nun von einer gewöhnlichen Session-ID? Eigentlich nicht mehr viel. Man kann genausogut 64 Zeichen lange Session-IDs generieren, die ein Angreifer ebenfalls irgendwie raten könnte - er muß ja einfach nur 64 korrekte Zeichen raten.

Hat das denn Sinn das alles in eine Zeichenkette zu machen? Die SessionID muß ja auf ale Fälle im Klartext vorliegen, daher favorisiere ich zur Zeit die Variante mit einem Cookie für SessionID und einem eigenen für die Authentifiztierungs-Konrolle mit Timestamp..., dann halt z.B. md5() verschlüsselt.

Ich denke, die Diskussion über Session-IDs läßt sich schlicht so subsummieren: Unratbar, wenn sie hinreichend lang ist - sie sollte nur einfach niemandem bekannt gemacht werden. Das ist ein viel größeres Problem. Unverschlüsselte Kommunikation ist dann natürlich ziemlich schlecht - da muß man nicht raten, man lauscht einfach in die Kommunikation hinein und kriegt alles geliefert, was man benötigt. Da ist es dann auch relativ egal, ob Sessions oder Authentifizierung verwendet werden.

Ich würde das aber nicht auf SesionIDs begrenzen, sondern das ist ein grundsätzlicheres Problem, was genau so bei htaccess auftritt!!! Wenn man eine unverschlüsselte htaccess-geschützte Verbindung abhört, ist es IMHO _SEHR_  viel einfacher, sich da einzuloggen, als wenn jemand einen md5() verschlüsselten String bekommt, denn bis der entschlüsselt ist ist die Session garantiert schon Monate lang abgelaufen. Nur leider muß man den ja nicht entschlüsseln, um sich in eine aktuelle Session einzuwählen... aber ist durch die zeitl. Begrenzung immer noch sicherer als htaccess, vor allem da das Passwort nicht erfährt!
Übrigens könnte man htaccess ja auch dadurch abbilden, indem man einfach das Passwort und den Benutzernamen in einem Cookie schreibt, und von mir aus verschlüsselt, dann hätte man doch etwa den gleichen Effekt(noch mit Verschlüsselung!), mit dem einen Unterschied, das man per Trojaner... sehr viel einfach er dran kommt. Gibt es def. keine Möglichkeit, auf einem PC die htaccess Zugangdaten irgendwie herauszubekommen? Das kann ich mir nicht vorstellen!

Das Problem besteht übrigens für jegliche Form der zusätzlichen Browsererkennung: Sie erhöht nur den Rateaufwand - wer erstmal spitzkriegt, daß er nur gewisse Bereiche des HTTP-Headers imitieren muß, wird defaultmäßig einfach zu einem identischen Browser, weil er alles kopiert, was der eigentliche Benutzer liefert. Hilft also nichts für die Sicherheit.

Aber das muß er auch erstmal spitzkriegen, oder? Und kann man so einfach immer zu einem identischen Browser werden? Woher soll er denn die ganzen Einstellungen kennen? Außerem kann er dann nur einen dummen Browser verwenden, kein Tool welches ihm per Bute Force... die Arbeit erleichtern kann. Wenn man tatsächlich am Anfang durch ein Javascript prüft, ob der Browser Jacascript kann, dann scheiden solche Tools auf alle Fälle aus, oder?

Wie macht man das eigentlich sinnvolerweise? Wie kann man das überprüfen?

Viele Grüße
Andeas

[Sven Rautenberg]

Moin!

Cookies _auch_ für die Session-ID, aber eben nicht nur.
Ich mache das dann mit Trans-SID, mit dem Fallback Mechanismus, falls Cookies nicht akzeptiert werden.

Das ist die übliche Vorgehensweise. Beachte, daß dann die Session-ID im Referrer drinstehen kann und auch an andere Server übertragen werden könnte. Deshalb nicht unbedingt wünschenswert.

Die bisherigen Überlegungen haben ja wohl ergeben, daß Cookies recht privat sind. Niemand sonst kriegt unbeabsichtigt Kenntnis. Also im Prinzip genau identisch, wie eine Benutzeranmeldung.

Das bezweifele ich aber! Ich hatte unbeabsichtigt innerhalb von 2-3 Wochen 3 Trojaner und 5 Würmer auf meinem Computer - ich denke das geht vielen Leuten nicht anders! Und ich bin der Überzeugung, das SEHR viel mehr Leute(Kinder) in der Lage sind private PCs auszuspionieren, als irgendwie den Traffic mitzulauschen, der bei mir SSL-verschlüsselt ist. Und ich denke, das es komplizierter ist, eine Variable aus dem http-Request des Browsers zu erfahren, als einen Cookie zu finden! Den/die kopiert auf den eigenen Rechner und schon geht alles wunderbar! Aber wie ich aus dem Browser die immer mitgeschickte SessionID bekommen sollte, wüßte ich nicht.

Wenn man bei dir unbemerkt Software installieren kann, dann kann man wahlweise am Datenverkehr deiner Netzwerkverbindung lauschen, oder am Tastaturport, wenn du die Paßwörter (dort noch unverschlüsselt) eingibst. Soll heißen: Wenn du deinem eigenen Rechner nicht vertraust, dann verschrotte ihn und geh' niemals mehr online! Denn dann ist ALLES unsicher, was du machst, egal ob dreifach verschlüsselte Paßwörter oder nur Session-ID via SSL übermittelt werden.

Aber was ist das für ein Unterschied ob in DB oder Session?  Wenn man den cookie hat ist es jawohl total egal wo das gespeichert ist! Ob man jetzt auf dem Server die Variable aus den Sessendaten ausliest, oder aus der Datenbank ist doch NULL Unterschied, oder? Nur das ich dann mit der DB enweder eine Session-Tabelle bräuchte, oder immer in der Benutzertabelle immer einen Timestamp überschreiben müßte - wobei ich hier natürlich prima prüfen könnte, ob der user nur einmal angemeldet ist, obwohl, das bringt ja nix wenn ich den Echten und den Angreifer nicht unterscheiden kann...
Aber erkläre mir Dein Unbehagen - kann ich nicht nachvollziehen?

Bei Licht betrachtet ist es auch irrational - wenn die Session-ID der Zugangsschlüssel zum Anmeldezeitpunkt ist, den der Server gespeichert hat, ist egal, wo und wie das gespeichert ist.

Wenn dann auch noch dieser Zeitstempel verschlüsselt wird, dann weiß man garnicht mehr, daß es ein Zeitstempel ist, und muß so richtig raten.
Aber ich denke das ein Zeitstemptel sehr beliebt ist, daher bräuchte ich vielleicht noch etwas, eine Kombination aus Timestamp + User Agent, oder aus den get_browser() Sachen, oder? Das dann verschlüsselt sollte schwieriger nachvollziebar sein.

Wie meine nachfolgenden Überlegungen ergeben haben, ist es vollkommener Quatsch, einen Zeitstempel oder irgendwelche sonstigen Zusätze zu benutzen: Das verlängert im Endeffekt nur die Session-ID, man hat also mehr Variantionen und entsprechend mehr Zeitaufwand beim Raten.

Wenn man dann das ganze noch weiter ausarbeitet, dann hat man im Prinzip eine längere Zeichenkette: 32 Zeichen Session-ID, und beispielsweise weitere 32 Zeichen verschlüsselter Timestamp, also 64 Zeichen. Was unterscheidet diese Zeichenkette nun von einer gewöhnlichen Session-ID? Eigentlich nicht mehr viel. Man kann genausogut 64 Zeichen lange Session-IDs generieren, die ein Angreifer ebenfalls irgendwie raten könnte - er muß ja einfach nur 64 korrekte Zeichen raten.
Hat das denn Sinn das alles in eine Zeichenkette zu machen? Die SessionID muß ja auf ale Fälle im Klartext vorliegen, daher favorisiere ich zur Zeit die Variante mit einem Cookie für SessionID und einem eigenen für die Authentifiztierungs-Konrolle mit Timestamp..., dann halt z.B. md5() verschlüsselt.

Es ist vollkommen egal, ob du Session-ID und weiteres Merkmal separat hälst oder zusammenpackst:

SID = abcdefg
Time= 20020603

Mal ein ganz einfaches Beispiel: Wenn man durch raten in solch ein System eindringen will, muß man 7 Buchstaben und 8 Zahlen richtig raten.

SIDTime = abcdefg20020603

Und bei diesem System muß man 7 Buchstaben und 8 Zahlen richtig raten.

Wenn du den Zeitstempel unverschlüsselt auf dem Server abspeicherst und dann verschlüssel im Cookie beim Browser, änderst du im Prinzip nur den String, der zu erraten ist. Statt 20020603 erscheint dann z.B. 67895674 als verschlüsselter String - viel geändert hat das aber nicht, da man wieder nur 8 Zahlen raten muß, diesmal verschärft um die Aufgabe, daß man nicht mehr so einfach sieht, was da mitgeschickt wird - es ist nicht offensichtlich das Tagesdatum, sondern eine Zufallszahl.

Ich denke, die Diskussion über Session-IDs läßt sich schlicht so subsummieren: Unratbar, wenn sie hinreichend lang ist - sie sollte nur einfach niemandem bekannt gemacht werden. Das ist ein viel größeres Problem. Unverschlüsselte Kommunikation ist dann natürlich ziemlich schlecht - da muß man nicht raten, man lauscht einfach in die Kommunikation hinein und kriegt alles geliefert, was man benötigt. Da ist es dann auch relativ egal, ob Sessions oder Authentifizierung verwendet werden.
Ich würde das aber nicht auf SesionIDs begrenzen, sondern das ist ein grundsätzlicheres Problem, was genau so bei htaccess auftritt!!!

Hab ich doch genau so gesagt.

Wenn man eine unverschlüsselte htaccess-geschützte Verbindung abhört, ist es IMHO _SEHR_  viel einfacher, sich da einzuloggen, als wenn jemand einen md5() verschlüsselten String bekommt, denn bis der entschlüsselt ist ist die Session garantiert schon Monate lang abgelaufen.

Nein, Denkfehler! Die Informationen im Cookie sind ja nur deshalb mit MD5 verschlüsselt, damit die darin enthaltenen Daten nicht so offensichtlich sind. Entschlüsselt werden die auf dem Webserver natürlich auch nicht, weils garnicht geht. Der Webserver erkennt die Session-ID, erfährt so den Zeitstempel, verschlüsselt den nochmal mit MD5 und vergleicht mit den Daten des Cookies. Ist alles identisch, scheint die Session vom berechtigten Rechner fortgesetzt worden zu sein.

Nur leider muß man den ja nicht entschlüsseln, um sich in eine aktuelle Session einzuwählen... aber ist durch die zeitl. Begrenzung immer noch sicherer als htaccess, vor allem da das Passwort nicht erfährt!

Tja, und da kommt eben zum Tragen, daß unverschlüsselte Verbindungen grundsätzlich unsicher sind. AuthType Digest verschlüsselt das Paßwort durch ein Challenge-Response-Verfahren - so erfahren lauschende Angreifer nicht mehr den Zugangsschlüssel, um später nochmal wiederzukommen.

Auch wenn Sessions scheinbar hier einen Vorteil haben: Irgendwann müssen die ja auch mal begonnen haben - mit dem unverschlüsselten Übertragen von Paßwort und Username mittels eines Formulars. Und wer das belauscht...

Übrigens könnte man htaccess ja auch dadurch abbilden, indem man einfach das Passwort und den Benutzernamen in einem Cookie schreibt, und von mir aus verschlüsselt, dann hätte man doch etwa den gleichen Effekt(noch mit Verschlüsselung!), mit dem einen Unterschied, das man per Trojaner... sehr viel einfacher dran kommt. Gibt es def. keine Möglichkeit, auf einem PC die htaccess Zugangdaten irgendwie herauszubekommen? Das kann ich mir nicht vorstellen!

Ich denke schon, daß es irgendwie durch ein installiertes Programm möglich ist, auch im Browser rumzulauschen. Aber wie schon gesagt: Wenn du nicht mal mehr davon ausgehen kannst, daß das gewählte Endgerät sicher ist, dann hast du sowieso ein Problem und kannst sichere Kommunikation total vergessen.

Aber das muß er auch erstmal spitzkriegen, oder? Und kann man so einfach immer zu einem identischen Browser werden? Woher soll er denn die ganzen Einstellungen kennen? Außerem kann er dann nur einen dummen Browser verwenden, kein Tool welches ihm per Bute Force... die Arbeit erleichtern kann. Wenn man tatsächlich am Anfang durch ein Javascript prüft, ob der Browser Jacascript kann, dann scheiden solche Tools auf alle Fälle aus, oder?

Wie man zu einem identischen Browser werden kann, zeigt Michael Schröpls Skript zum Servercheck. Denk dir einfach ein Skript, welches als Proxy arbeitet, also den dahinterstehenden Browser total verdeckt und alle HTTP-Header durch die des zu imitierenden Opfers ersetzt - der Server wird den Unterschied nicht mehr feststellen können, allerhöchstens (und dagegen kann man durch Verwendung eines zumindest in die Serie passenden Browsers etwas unternehmen) wird ein IE niemals document.layers verstehen - das könnte ja irgendwie zum Server zurückübermittelt werden.

In diesem Zusammenhang: Die PHP-Funktion get_browser() ist ziemlich billig aufgebaut. Sie schaut in einer Textdatenbank nach, was der Browser im allgemeinen so kann, und zerpflückt ein wenig den User-Agent in seine Bestandteile. Eine Information über den real verwendeten Browser und seine Möglichkeiten ist das nicht.

Ich fasse nochmal zusammen: Der einzige Schutz der jetzt von uns diskutierten Methoden ist der, daß man davon ausgeht, daß ein Angreifer nicht exakt die gleichen Informationen senden kann wie ein ordentlicher Benutzer. Dies wird im Allgemeinen dadurch erreicht, daß ordentliche Benutzer keine Klartextinformationen vom Server erhalten, und daß die Vielfalt der Ratemöglichkeiten hinreichend groß ist.

Sessionbasierte Mechanismen haben den leichten Vorteil, daß im Prinzip nach erfolgter Authentifizierung, bei der einmal Username und Paßwort übermittelt wurden, ein Einmal-Zugangsschlüssel (nämlich die Session-ID, meinetwegen angereichert um gewisse Zusatzinformationen) erstellt wird, der irgendwann ungültig wird und dann keine weiteren Benutzungen mehr zuläßt. Diese Methode hilft bei zufällig nach außen gelangten Sessiondaten etwas, den Mißbrauch einzudämmen, ist aber trotzdem nur ein extremst schwacher Schutz. Viel wichtiger ist SSL.

Letztendlich ist alles nur eine Frage des Rateaufwandes. Man kann auch Benutzernamen und Paßwörter raten und bei Erfolg Zugang erhalten - egal welcher Mechanismus benutzt wird: Sessions, .htaccess, irgendwas mit SSL. Der Schwachpunkt hierbei ist, wie immer, der Mensch, der sich einfach keine ordentlichen Paßwörter merken kann, sondern den Vornamen der Frau plus das Alter der Kinder nimmt (wobei das Paßwort da ja immerhin noch jedes Jahr gewechselt wird <eg>).

- Sven Rautenberg

[Andreas]

Hallo!

Wenn man bei dir unbemerkt Software installieren kann, dann kann man wahlweise am Datenverkehr deiner Netzwerkverbindung lauschen, oder am Tastaturport, wenn du die Paßwörter (dort noch unverschlüsselt) eingibst.

Naja, 'man' ist vielleicht das falsche Wort, die machen das ja mehr oder weniger von alleine, aober ich will mich ja auch nicht rausreden...

Wie meine nachfolgenden Überlegungen ergeben haben, ist es vollkommener Quatsch, einen Zeitstempel oder irgendwelche sonstigen Zusätze zu benutzen: Das verlängert im Endeffekt nur die Session-ID, man hat also mehr Variantionen und entsprechend mehr Zeitaufwand beim Raten.

Nein, das sehe ich absolut anders! Du mußt nicht immer von irgendwelchen Profi-Crackern ausgehen(die würden die Versuche hier eh nur belächeln :-)), aber es gibt ja zig Schattierungen, und je mehr Features man da einbaut desto kleiner wird der Kreis der Leute, die tatsächlich noch Schaden anrichten können! Und nicht nur das: der Angreifer weiß ja nicht, was man da noch verwendet - die SessionID sieht er sofort und kommt da recht problemlos dran, z.B. über irgendwelche referer-Logs. aber da stehe ja garantiert keine Cookie-Daten drin, also um an die Cookiedaten zu kommen, müßte er entweder auf den Clientrechner, was wir hier ja ausklammern wollen, oder die Verbindung irgendwo belauschen, und das ist nicht so einfach denke ich. Wobei ich mich tatsächlich frage, wenn man SSL verwendet - derjenige der es schafft an SSl vorbei zu kommen, für den ist der Rest dann ein Kinderspiel, oder? Aber dann müßte auch sichergestellt sein, das nirgendwo die Referer... geloggt werden. Nicht das jemand dann auf ne andere Seite geht ohne sich abzumelden, dann hätten wir das ja wieder in nem unsicheren Bereich in nem Referer stehe, also ist das mit dem Cookie und Tiemstamp vielleicht doch nicht so dumm, oder?

Es ist vollkommen egal, ob du Session-ID und weiteres Merkmal separat hälst oder zusammenpackst:

SID = abcdefg
Time= 20020603

Mal ein ganz einfaches Beispiel: Wenn man durch raten in solch ein System eindringen will, muß man 7 Buchstaben und 8 Zahlen richtig raten.

SIDTime = abcdefg20020603

Und bei diesem System muß man 7 Buchstaben und 8 Zahlen richtig raten.

Wenn du den Zeitstempel unverschlüsselt auf dem Server abspeicherst und dann verschlüssel im Cookie beim Browser, änderst du im Prinzip nur den String, der zu erraten ist. Statt 20020603 erscheint dann z.B. 67895674 als verschlüsselter String - viel geändert hat das aber nicht, da man wieder nur 8 Zahlen raten muß, diesmal verschärft um die Aufgabe, daß man nicht mehr so einfach sieht, was da mitgeschickt wird - es ist nicht offensichtlich das Tagesdatum, sondern eine Zufallszahl.

Das ist alles richtig, nur bedenke, dass die SessionID nicht gerade kurz ist, und ein md5(microtime()) ist auch nicht ganz so leicht per bruteforce zu erraten, oder? Wenn Du diebeiden Sachen zusammennimmst, dann zeig mir mal jemanden, der eine Gültige kombination errät, die auch zufälligerweise ausgerechnet zudem zeitpunkt 40 Minuten existiert, ich denke da braucht man gar nicht so schwarz zu sehen! und außerdem dauern die Anfragen über http immer so Ihre Zeit, also das zu erraten halte ich für (fast) unmöglich.

Tja, und da kommt eben zum Tragen, daß unverschlüsselte Verbindungen grundsätzlich unsicher sind. AuthType Digest verschlüsselt das Paßwort durch ein Challenge-Response-Verfahren - so erfahren lauschende Angreifer nicht mehr den Zugangsschlüssel, um später nochmal wiederzukommen.

Wobei ich da mal anmerken will, ich habe mir gerade mal ein kleines Tootl zum testen gesucht, war nicht besonders, aber damit konnte ich mich mal selbst belauschen :-) Und wenn man sowas irgendwo dazwischen hätte... man, man. Cookies... alles bekommt man damit, ist ja klar! Aber was mich erstaunt hat, htaccess Benutzerdaten waren verschlüsselt! War Basic! Aber das war kein Klartext, was da stand!!!

Auch wenn Sessions scheinbar hier einen Vorteil haben: Irgendwann müssen die ja auch mal begonnen haben - mit dem unverschlüsselten Übertragen von Paßwort und Username mittels eines Formulars. Und wer das belauscht...

Ja, aber belauschen, dann mußt Du aber auf einem Rechner zwischendurch ein programm installieren können, und das stelle ich mir nicht so einfach vor! ich denke die Rechner +über die richtige Internetverbindungen laufen, sollten doch einigermaßen schwierig zu knacken sein, oder? Aber das hatten wir ja schon, wenn man belauschen kann ist eh alles vorbei...

In diesem Zusammenhang: Die PHP-Funktion get_browser() ist ziemlich billig aufgebaut. Sie schaut in einer Textdatenbank nach, was der Browser im allgemeinen so kann, und zerpflückt ein wenig den User-Agent in seine Bestandteile. Eine Information über den real verwendeten Browser und seine Möglichkeiten ist das nicht.

Ja, das ist mir klar! Aber ich vermute, das sich die Einstellungen über eine Session nicht ändern, ob das jetzt stimmt oder nicht, und das ist entscheidend, mir ist total egal ob das jetzt ein Ferrari xyz oder was auch immer ist, Hauptsache es bleibt ein Ferrari und kein Proxy oder so macht daraus einen Ferrari xyz 145533532!

Ich fasse nochmal zusammen: Der einzige Schutz der jetzt von uns diskutierten Methoden ist der, daß man davon ausgeht, daß ein Angreifer nicht exakt die gleichen Informationen senden kann wie ein ordentlicher Benutzer. Dies wird im Allgemeinen dadurch erreicht, daß ordentliche Benutzer keine Klartextinformationen vom Server erhalten,

Damit meinst Du SSL, oder?

und daß die Vielfalt der Ratemöglichkeiten hinreichend groß ist.

damit meinst Du einen Timestamp oder sowas, oder?

Sessionbasierte Mechanismen haben den leichten Vorteil, daß im Prinzip nach erfolgter Authentifizierung, bei der einmal Username und Paßwort übermittelt wurden, ein Einmal-Zugangsschlüssel (nämlich die Session-ID, meinetwegen angereichert um gewisse Zusatzinformationen) erstellt wird, der irgendwann ungültig wird und dann keine weiteren Benutzungen mehr zuläßt. Diese Methode hilft bei zufällig nach außen gelangten Sessiondaten etwas, den Mißbrauch einzudämmen, ist aber trotzdem nur ein extremst schwacher Schutz. Viel wichtiger ist SSL.

Das stimmt, aber das war mir vorher klar und wird auch verwendet, mich interessieren halt noch die anderen Möglichkeiten!

Letztendlich ist alles nur eine Frage des Rateaufwandes. Man kann auch Benutzernamen und Paßwörter raten und bei Erfolg Zugang erhalten - egal welcher Mechanismus benutzt wird:

Sessions, .htaccess, irgendwas mit SSL. Der Schwachpunkt hierbei ist, wie immer, der Mensch, der sich einfach keine ordentlichen Paßwörter merken kann, sondern den Vornamen der Frau plus das Alter der Kinder nimmt (wobei das Paßwort da ja immerhin noch jedes Jahr gewechselt wird <eg>).
Ja, aber man kann den Rateaufwand ja derart groß machen, das kein Großrechner der Welt das innnerhalb einer Session schafft, oder? Aber Du sprichst was anders an, das einloggen ist natürlich eine ganz andere Sicheheitslücke! Wie kann man sinnvoll verhindern, das sich jemand mit einem Script per Bruteforce probiert einzuloggen? Cookies haben keinen Sinn. Wi könnte man das sonst wirkunksvoll verhindern?

Grüße
Andreas

[Sven Rautenberg]

Nochmal Moin!

Wie meine nachfolgenden Überlegungen ergeben haben, ist es vollkommener Quatsch, einen Zeitstempel oder irgendwelche sonstigen Zusätze zu benutzen: Das verlängert im Endeffekt nur die Session-ID, man hat also mehr Variantionen und entsprechend mehr Zeitaufwand beim Raten.
Nein, das sehe ich absolut anders! Du mußt nicht immer von irgendwelchen Profi-Crackern ausgehen(die würden die Versuche hier eh nur belächeln :-)), aber es gibt ja zig Schattierungen, und je mehr Features man da einbaut desto kleiner wird der Kreis der Leute, die tatsächlich noch Schaden anrichten können!

Wenn man ein sicheres System basteln will, muß man von Profi-Crackern ausgehen. Und ich würde nicht behaupten, daß die hierüber lächeln würden. Im Zweifel würden die andere Angriffspunkte finden, aber eher  nicht die Session selbst angreifen.

Und nicht nur das: der Angreifer weiß ja nicht, was man da noch verwendet - die SessionID sieht er sofort und kommt da recht problemlos dran, z.B. über irgendwelche referer-Logs. aber da stehe ja garantiert keine Cookie-Daten drin, also um an die Cookiedaten zu kommen, müßte er entweder auf den Clientrechner, was wir hier ja ausklammern wollen, oder die Verbindung irgendwo belauschen, und das ist nicht so einfach denke ich.

Die Session-ID ist dann im Referrer, wenn kein Cookie verwendet wurde. Entweder - oder.

Sieh es doch einfach mal aus Angreifersicht:

Der Angreifer sieht folgenden Referrer-Bestandteil:
?SESSID=lkgsedfzuiz2978swefhiase67aw4a8wrhiuaw4zp98zhuiaw4z879paw4

Frage: Welcher Teil dieses Strings ist die eigentliche Session-ID, welcher Teil ist der Timestamp, und welcher Teil ist der User-Agent? Oder welche anderen Teile sind dort verwurstelt?

Die Antworten auf die Frage ist total egal. Wenn man den Referrer im Browser aufruft, dann führt diese Session-ID dazu, daß der Server eine Seite ausliefert.

Warum? Weil in der URL alle Informationen codiert sind, die auch der reguläre Browser mitsenden würde. Es ist vollkommen uninteressant, ob der Server die ID zerlegt, einen Zeitstempel prüft, oder sonstwas an den Browsereigenschaften (wobei die ja alle nicht zuverlässig genug sind, weil entweder zu veränderlich, wie die IP oder der User-Agent, oder zu wenig verschieden, wie die Liste der akzeptierten MIME-Typen): Diese komplette ID (sei sie nun komplett oder bereits vorzerlegt) erlaubt den Zugriff auf den Server - der reguläre Benutzer kriegt ihn ja schließlich.

Das einzig interessante ist: Wieviele verschiedene Möglichkeiten hat die Session-ID insgesamt, und wieviele Sessions sind zeitgleich in Betrieb - also: wie erfolgreich ist man beim Raten.

Eine gewöhnliche PHP-Session-ID besteht aus 32 hexadezimalen Zeichen, also 32 * 16 Zeichen. Das ergibt 16^32 verschiedene Session-IDs, also genau 3,4028236692093846346337460743177e+38. Wieviele Sessions laufen parallel? Nehmen wir mal grob eine Million (also 1e+6). Folglich ist die Chance, eine aktive Session zu raten, 1:3,4e+32.

6 richtige im Lotto kriegt man mit der Chance 1:13.983.816 - ich würde dann lieber Lottospielen, als Sessions zu raten.

Aber: Lottospielen kostet Geld, und die Ziehung ist nur einmal die Woche - der Server ist immer ansprechbar.

Rechnen wir mal weiter: Wieviele verschiedene Sessions kann man pro Sekunde prüfen? Wenn der Server nicht total überlastet werden soll, nehmen wir doch mal einfach als Hausnummer 10.000 Sessions pro Sekunde.

Dann braucht man immer noch durchschnittlich 3,4e+28 Sekunden, um die erste Session zu raten. Oder 10^21 Jahre. Das sind 1 Trilliarden Jahre. Das dauert doch eine Weile.

Du siehst also: Sessions raten dürfte reichlich unmöglich sein - da kriegt man Zufallstreffer, und auch die nur sehr selten - wenn der Rest der Serverimplementation ordentlich arbeitet.

Wenn zusätzlich noch SSL zum Zuge kommt, dann ist anhand der übermittelten Verbindungsdaten annähernd ausgeschlossen, daß jemand die belauscht und deshalb ebenfalls Zugriff erlangt.

SSL darf als sicher betrachtet werden - solange man die stärkste Verschlüsselungsstufe mit 128 Bit verwendet. 40 Bit Schlüssellänge sind nicht mehr ausreichend. Ich weiß nicht, wie lange man zur Überwindung solch eines Schlüssels benötigt, aber wahrscheinlich länger, als eine Session andauert.

Auf den Rest gehe ich jetzt einfach nicht mehr weiter ein, denn ich würde die Diskussion einfach einem Ende zuführen. :)

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

Der Angreifer sieht folgenden Referrer-Bestandteil:
?SESSID=lkgsedfzuiz2978swefhiase67aw4a8wrhiuaw4zp98zhuiaw4z879paw4
Frage: Welcher Teil dieses Strings ist die
eigentliche Session-ID, welcher Teil ist der
Timestamp, und welcher Teil ist der User-Agent?
Oder welche anderen Teile sind dort verwurstelt?
Die Antworten auf die Frage ist total egal.
Wenn man den Referrer im Browser aufruft, dann führt
diese Session-ID dazu, daß der Server eine Seite
ausliefert.

Das ist dann aber ein schlechter Session-Mechanismus.

Warum? Weil in der URL alle Informationen codiert
sind, die auch der reguläre Browser mitsenden würde.

Genau das ist der Fehler dabei.

Es ist vollkommen uninteressant, ob der Server die
ID zerlegt, einen Zeitstempel prüft, oder sonstwas
an den Browsereigenschaften (wobei die ja alle nicht
zuverlässig genug sind, weil entweder zu
veränderlich, wie die IP oder der User-Agent, oder
zu wenig verschieden, wie die Liste der akzeptierten
MIME-Typen): Diese komplette ID (sei sie nun
komplett oder bereits vorzerlegt) erlaubt den
Zugriff auf den Server - der reguläre Benutzer
kriegt ihn ja schließlich.

Nein. Der reguläre Benutzer bekommt den Zugriff genau
dann, wenn der Server ihm diesen erlaubt.
Und genau wie bei Server Authentication oder Content
Negotiation ist der URL eben _nicht_ eine hinreichende,
eindeutige Beschreibung der Ressource, sondern die
restlichen HTTP-Header können den Effekt der Anforde-
rung beliebig beeinflussen.

Wenn der Server die Session-ID so zerlegen kann, daß
er prüfen kann, ob die restlichen HTTP-Header dazu
passen, dann kann er dem normalen Benutzer den Zugriff
erlauben und dem Angreifer den Zugriff auf denselben
URL verbieten.

Erst vor ein paar Tagen hatte Sabine Pekarz einen
schönen langen Thread zu diesem Thema im Forum gestartet, wo wir darüber diskutierten, welche Felder des HTTP-Request als zusätzliche Prüfsummen taugen - mit dem Tenor "je variabler die Werte, desto besser".
Also in erster Linie der UserAgent. Daß der Benutzer
dessen Wert verändert kann, schadet doch nichts -
solange er das nicht innerhalb einer Session tut.

Viele Grüße
      Michael

[Sven Rautenberg]

Hi Sven,

Der Angreifer sieht folgenden Referrer-Bestandteil:
?SESSID=lkgsedfzuiz2978swefhiase67aw4a8wrhiuaw4zp98zhuiaw4z879paw4
Frage: Welcher Teil dieses Strings ist die
eigentliche Session-ID, welcher Teil ist der
Timestamp, und welcher Teil ist der User-Agent?
Oder welche anderen Teile sind dort verwurstelt?
Die Antworten auf die Frage ist total egal.
Wenn man den Referrer im Browser aufruft, dann führt
diese Session-ID dazu, daß der Server eine Seite
ausliefert.

Das ist dann aber ein schlechter Session-Mechanismus.

Die Kombination Username/Passwort bei .htaccess ist nicht besser. Statt einer Session-ID wird eben diese Info übermittelt, und der Server liefert was aus. Ist .htaccess etwa auch schlecht?

Warum? Weil in der URL alle Informationen codiert
sind, die auch der reguläre Browser mitsenden würde.

Genau das ist der Fehler dabei.

Nein. Der reguläre Benutzer bekommt den Zugriff genau
dann, wenn der Server ihm diesen erlaubt.
Und genau wie bei Server Authentication oder Content
Negotiation ist der URL eben _nicht_ eine hinreichende,
eindeutige Beschreibung der Ressource, sondern die
restlichen HTTP-Header können den Effekt der Anforde-
rung beliebig beeinflussen.

Wenn der Server die Session-ID so zerlegen kann, daß
er prüfen kann, ob die restlichen HTTP-Header dazu
passen, dann kann er dem normalen Benutzer den Zugriff
erlauben und dem Angreifer den Zugriff auf denselben
URL verbieten.

Das bietet aber keine zusätzliche Sicherheit. Wenn der Angreifer ganz stumpf den kompletten HTTP-Header des Browsers kopiert (was ja nicht ausgeschlossen werden kann, vor allem, wenn dieser Mechanismus bekannt ist - Security by Obscurity war noch nie ein guter Ratgeber), dann kriegt er ebenso Zugriff.

Erst vor ein paar Tagen hatte Sabine Pekarz einen
schönen langen Thread zu diesem Thema im Forum gestartet, wo wir darüber diskutierten, welche Felder des HTTP-Request als zusätzliche Prüfsummen taugen - mit dem Tenor "je variabler die Werte, desto besser".
Also in erster Linie der UserAgent. Daß der Benutzer
dessen Wert verändert kann, schadet doch nichts -
solange er das nicht innerhalb einer Session tut.

Es wurde vermutet, daß Proxyserver möglicherweise einen Zeitstempel irgendwo reinsetzen könnten. Wäre dann nicht gut für die Funktionalität, und Benutzer könnten darauf möglicherweise keinerlei Einfluß haben, weil sie den Proxy zwingend benutzen müssen.

Wie gesagt: Man kann Session-IDs raten. Man kann Username/Paßwort raten. Wer ungestört andere eine Million mal raten läßt, ist selber Schuld. Bei der nur vierstelligen Geldautomaten-PIN hat man drei Versuche bei 10.000 Möglichkeiten. Es wäre kein Beinbruch, bei 10^38 Session-IDs einfach 10 Rateversuche zu erlauben, und danach die Kommunikation einzustellen. Hattest du ja aber schon selbst gefordert. Ich denke nicht, daß zusätzliche Merkmalsprüfung die Sicherheit wirklich qualitativ erhöht - sie erhöht den Rateaufwand, weil mehr gesendete Informationen übereinstimmen müssen. Wer die Session-ID mittels Referrer auf seinen Server locken kann, kriegt grundsätzlich alle HTTP-Header des Browsers übermittelt und kann sie zum Angriff einsetzen - wo ist da die zusätzliche Sicherheit?

- Sven Rautenberg

[Andreas]

Hallo!

Es wurde vermutet, daß Proxyserver möglicherweise einen Zeitstempel irgendwo reinsetzen könnten. Wäre dann nicht gut für die Funktionalität, und Benutzer könnten darauf möglicherweise keinerlei Einfluß haben, weil sie den Proxy zwingend benutzen müssen.

Wie gesagt: Man kann Session-IDs raten. Man kann Username/Paßwort raten. Wer ungestört andere eine Million mal raten läßt, ist selber Schuld. Bei der nur vierstelligen Geldautomaten-PIN hat man drei Versuche bei 10.000 Möglichkeiten. Es wäre kein Beinbruch, bei 10^38 Session-IDs einfach 10 Rateversuche zu erlauben, und danach die Kommunikation einzustellen. Hattest du ja aber schon selbst gefordert. Ich denke nicht, daß zusätzliche Merkmalsprüfung die Sicherheit wirklich qualitativ erhöht - sie erhöht den Rateaufwand, weil mehr gesendete Informationen übereinstimmen müssen. Wer die Session-ID mittels Referrer auf seinen Server locken kann, kriegt grundsätzlich alle HTTP-Header des Browsers übermittelt und kann sie zum Angriff einsetzen - wo ist da die zusätzliche Sicherheit?

ich will das hier auc gar nicht mehr groß ausdehnen, aber Dein Tenor ist ja im prinzip - "Lasse alles wie es ist und bau ein paar Sicherungen ein, das man nicht so ohne weiters raten kann", oder?

Die Zusätzliche Sicherheit aus Timestamp etc. wäre doch einfach wenn man Cookies vorschreibt und diese Information darin speichert! Der Cookie wird wohl nirgendwo geloggt und um da dran zu kommen müßte man nicht nur an irgendwelche Logfiles kommen, sondern an einem der Rechner oder irgendwo dazwischen lauschen, was  meiner Meinung nach ein ganz erheblicher Unterschied ist! Auch das Codieren oder mit anderen Header Informationen anreichern bringt wohl nichts, denn nicht das erraten des Wertes im Cookie ist das problem(selbst wenn man das könnte), sondern wohl eher diesen Cookie nachzubauen, und das wird man nur schaffen, wenn man den Verkehr belauscht. Oder? Ist doch so das cookies durch irgendeinen Mechanismus nur an den einen Server geschickt werden, ich denke nicht das man sich so ohne weiteres einen eigenen Cookie basteln kann, oder?

Viele Grüße und Danke Euch beiden und vor allem Sven für die sehr hilfreichen und ausführlichen Antworten, und den ich auch gar nicht weiter nerven möchte :-)

Andreas

[Sven Rautenberg]

Auf ein letztes Mal! :)

ich will das hier auc gar nicht mehr groß ausdehnen, aber Dein Tenor ist ja im prinzip - "Lasse alles wie es ist und bau ein paar Sicherungen ein, das man nicht so ohne weiters raten kann", oder?

Richtig. Die Frage ist: Wie gut werden von PHP die Session-IDs generiert? Wie zufällig sind sie? Vermutlich läßt sich das irgendwo nachlesen, daß die Systemzeit MD5-verschlüsselt wird, vorher noch einen Zufallswert mitkriegt, und fertig. Wenn du diesem noch einen Timestamp hinzufügst, kriegst du nicht notwendigerweise mehr Sicherheit rein (es können immer noch zwei User gleichzeitig eine Session eröffnen), du kriegst nur längere Session-IDs, die schwerer zu raten sind. Das ist grundsätzlich nicht schlecht, also spricht nichts dagegen, es zu machen. Es bringt aber nicht notwendigerweise den ultimativen Sicherheitsgewinn, den du dir davon versprichst.

Die Zusätzliche Sicherheit aus Timestamp etc. wäre doch einfach wenn man Cookies vorschreibt und diese Information darin speichert! Der Cookie wird wohl nirgendwo geloggt und um da dran zu kommen müßte man nicht nur an irgendwelche Logfiles kommen, sondern an einem der Rechner oder irgendwo dazwischen lauschen, was  meiner Meinung nach ein ganz erheblicher Unterschied ist! Auch das Codieren oder mit anderen Header Informationen anreichern bringt wohl nichts, denn nicht das erraten des Wertes im Cookie ist das problem(selbst wenn man das könnte), sondern wohl eher diesen Cookie nachzubauen, und das wird man nur schaffen, wenn man den Verkehr belauscht. Oder? Ist doch so das cookies durch irgendeinen Mechanismus nur an den einen Server geschickt werden, ich denke nicht das man sich so ohne weiteres einen eigenen Cookie basteln kann, oder?

Ob mit Timestamp oder ohne: Der Cookie wird vom Browser wirklich nur an den Server geschickt - wer da ran will, muß lauschen. Insofern schränkt das die Zahl der möglichen Angreifer ein: Die Mehrzahl der Benutzer im Netz wird als Angreifer ausscheiden, hingegen ist eine interessante Gruppe von Angreifern weiterhin im Spiel: Die lieben Kollegen, welche im gleichen Netzwerk hängen (das kann auch durch einen Switch nicht ausgeschlossen werden), und natürlich der Systemadministrator - der kann sowieso alle Netzverbindungen belauschen, nur bei SSL muß er aufgeben. Bei diesen Personengruppen ist die persönliche Beziehung zum Opfer sehr interessant - irgendein anonymer Mensch ist viel uninteressanter als der Schnösel von nebenan, wenn man z.B. Material fürs Mobbing sucht.

Viele Grüße und Danke Euch beiden und vor allem Sven für die sehr hilfreichen und ausführlichen Antworten, und den ich auch gar nicht weiter nerven möchte :-)

Du siehst: Sicherheit ist ein sehr komplexes Thema. Man muß immer abwägen, was man will, und wie wichtig einem Sicherheit ist, bzw. wie wichtig das für die Benutzer sein könnte.

- Sven Rautenberg

[Michael Schröpl]

Hi Andreas,

Die Zusätzliche Sicherheit aus Timestamp etc. wäre
doch einfach wenn man Cookies vorschreibt und diese
Information darin speichert!
Der Cookie wird wohl nirgendwo geloggt und um da
dran zu kommen müßte man nicht nur an irgendwelche
Logfiles kommen, sondern an einem der Rechner oder
irgendwo dazwischen lauschen, was  meiner Meinung
nach ein ganz erheblicher Unterschied ist!

dasselbe gilt aber auch für den UserAgent - beides
sind HTTP-Header.
Wenn Du sicher bist, daß der Cookie nicht belauscht
werden kann, dann ist auch der UserAgent nicht be-
lauschbar - und in _diesem_ Szenario bringt er eine
zusätzliche Prüfsumme in die Session-ID ein.

Ist doch so das cookies durch irgendeinen
Mechanismus nur an den einen Server geschickt
werden

Alles, was "nur an diesen Server" gesendet wird,
wandert aber vorher durch diverse andere Maschinen,
die eventuell lauschen könnten.

ich denke nicht das man sich so ohne weiteres
einen eigenen Cookie basteln kann, oder?

Doch, das kann man natürlich.
Man muß nur erraten, was drin stehen müßte - wie bei
jedem anderen HTTP-Header, den Du verwendest, auch.

Viele Grüße
      Michael

[Andreas]

Hallo!

Ihr verwirrt mich ganz schön ;-)

Der Cookie wird wohl nirgendwo geloggt und um da
dran zu kommen müßte man nicht nur an irgendwelche
Logfiles kommen, sondern an einem der Rechner oder
irgendwo dazwischen lauschen, was  meiner Meinung
nach ein ganz erheblicher Unterschied ist!

dasselbe gilt aber auch für den UserAgent - beides
sind HTTP-Header.

EBEN NICHT!!! Der USer-Agent wird oft in Logfiles direkt neben dem referer geschrieben, da hat man ja direkt beides zusammen, da braucht man dann nicht mehr viel raten, daher meine Bedenken in diese Richtung! Der Cookie dagegen kann nur durch lauschen "abgefangen" werden, IMHO ein erhebliche Unterschied! Oder wo werden cookies geloggt???? ich gehe jetzt von dem Szenario aus, das ich mit SSL verschlüssel. Das heißt, lauschen ist wirklich nur mit sehr hohem Aufwand möglich, denke ich. Also soßllte ein cookie schonmal sicher sein, genauso alle anderen Daten die in keinen Logfiles erscheinen und immer unverändert bleiben. Jetzt ist nur noch die Frage, ob es noch Sinn macht zu der Session ID, die wenn möglich auch in einem cookie übertragen wird, noch den User-Agent zu verwenden - bringt das noch einen großen Gewinn an Sicherheit? Ich weiß jetzt nicht wie groß sich der Aufwand eine SessionId aus Logfiles oder wie auch immer zu bekommen, vom Aufwand die SessionID + dazugehörigen User-Agent zu bekommen, unterscheidet. Wenn im Cookie eine md5-codierte Kombination aus Zufallszahl und microtime() steht, sollte die auch schwer zu erraten sein, geschweige denn ohne gelauscht zu haben ins blaue einen Cookie zu erstellen. Das ist ja nicht nur ne Ascii Datei, sondern auch irgendwie eindeutig einem Server zugeordnet, und wie man das nachbildet ist meines Wissens nicht einfach.
Ich tendiere aber im Augenblick anstatt User-Agent eher zur PHP-Funktion get_browser(), ist in diesem Falle ja egal wie genau das ist, Hauptsache konstant - der Vorteil: Die Funktion bezieht Ihre Informationen nucht nur aus dem user-Agent, also ist die Hürde wieder eine Stufe höher angelegt, denke ich. Vielleicht sollte man auch beides noch kombinbieren, naja...
Das einzige was dann noch fehlt, ist sicher dafür zu sorgend, das niemand irgendwelche Rate-Attacken starten kann, aber das ist ein anderes Thema, und wir wollen ja auch langsam mal zum Punkt kommen, was?

Jedenfalls Danke nochmal für die interesante Diskussion, habe dabei einiges lernen können!

Viele Grüße
Andreas

PS: jetzt muß ich aber langsam ins Bett... ;-)

[Sven Rautenberg]

Ein letztes Mal Hallo! ;)

Ihr verwirrt mich ganz schön ;-)

Der Cookie wird wohl nirgendwo geloggt und um da
dran zu kommen müßte man nicht nur an irgendwelche
Logfiles kommen, sondern an einem der Rechner oder
irgendwo dazwischen lauschen, was  meiner Meinung
nach ein ganz erheblicher Unterschied ist!

dasselbe gilt aber auch für den UserAgent - beides
sind HTTP-Header.

EBEN NICHT!!! Der USer-Agent wird oft in Logfiles direkt neben dem referer geschrieben, da hat man ja direkt beides zusammen, da braucht man dann nicht mehr viel raten, daher meine Bedenken in diese Richtung! Der Cookie dagegen kann nur durch lauschen "abgefangen" werden, IMHO ein erhebliche Unterschied! Oder wo werden cookies geloggt????

Man kann Cookies auch loggen. Man kann so ziemlich alles loggen, was der Webserver erfährt. Apache ist da sehr flexibel.

ich gehe jetzt von dem Szenario aus, das ich mit SSL verschlüssel. Das heißt, lauschen ist wirklich nur mit sehr hohem Aufwand möglich, denke ich. Also soßllte ein cookie schonmal sicher sein, genauso alle anderen Daten die in keinen Logfiles erscheinen und immer unverändert bleiben. Jetzt ist nur noch die Frage, ob es noch Sinn macht zu der Session ID, die wenn möglich auch in einem cookie übertragen wird, noch den User-Agent zu verwenden - bringt das noch einen großen Gewinn an Sicherheit?

Mit jedem Byte zusätzlicher Länge der Session-ID erhöhst du potentiell den Rateaufwand um das 16 bis 256fache - je nach Zeichenbereich. Wenn du die Session-ID also sehr lang machst, lohnt sich ein Raten kaum noch, und Zufallsergebnisse sind dann extrem selten. Ich hatte dir ja aber schon vorgerechnet, daß die normalen PHP-Sessions ziemlich unmöglich auszuprobieren sind, und auch Raten trifft extremst viel seltener, als 6 Richtige im Lotto.

Ich weiß jetzt nicht wie groß sich der Aufwand eine SessionId aus Logfiles oder wie auch immer zu bekommen, vom Aufwand die SessionID + dazugehörigen User-Agent zu bekommen, unterscheidet. Wenn im Cookie eine md5-codierte Kombination aus Zufallszahl und microtime() steht, sollte die auch schwer zu erraten sein, geschweige denn ohne gelauscht zu haben ins blaue einen Cookie zu erstellen. Das ist ja nicht nur ne Ascii Datei, sondern auch irgendwie eindeutig einem Server zugeordnet, und wie man das nachbildet ist meines Wissens nicht einfach.

Wenn du nur die Session-ID benutzt, hast du praktisch keinen Zusatz-Programmieraufwand dafür. Wenn du zusätzliche Merkmale prüfen willst, die aber absolut nicht fälschungssicher sind, hast du den Zusatzaufwand, das auf dem Server irgendwo zu speichern und zu prüfen.

Ein Cookie ist HTTP-technisch betrachtet einfach nur ein weiteres Feld des Headers. Es ist keine ASCII-Datei (bedenke: Nur der IE legt pro Server eine einzelne Cookie-Datei an, der Netscape packt alle Cookies in _eine_ Datei). Wenn man das imitieren will, braucht man lediglich ein Programm, welches als HTTP-Client auftreten kann und in der Lage ist, selbstdefinierte HTTP-Header (also zum Beispiel die eines beliebigen Browsers inklusive Cookies etc.) zu senden und die Antwort des Servers entgegenzunehmen. Es wäre unwahrscheinlich anzunehmen, daß ein Angreifer Session-IDs per Hand in die URL eintippert - das machen, wenn überhaupt, Skripte.

Ich tendiere aber im Augenblick anstatt User-Agent eher zur PHP-Funktion get_browser(), ist in diesem Falle ja egal wie genau das ist, Hauptsache konstant - der Vorteil: Die Funktion bezieht Ihre Informationen nucht nur aus dem user-Agent, also ist die Hürde wieder eine Stufe höher angelegt, denke ich. Vielleicht sollte man auch beides noch kombinbieren, naja...

get_browser() untersucht den User-Agent und zieht aufgrund dessen Informationen aus einer lokalen Datenbank. Damit gewinnst du nichts, sondern generalisierst. Aus einem T-Online-IE 5.5 mit netter Seriennummer (irgendwelche User-Agents haben recht individuelle Zahlenkombinationen drin) wird dann ein ganz allgemeiner IE 5.5 - da alle IEs Javascript, JScript und VBScript können, kriegst du bei diesen Daten immer "ja" als Antwort, auch wenn es abgeschaltet ist. Mit anderen Worten: Nicht empfehlenswert.

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

dran zu kommen müßte man nicht nur an irgendwelche
Logfiles kommen, sondern an einem der Rechner oder
irgendwo dazwischen lauschen, was  meiner Meinung
nach ein ganz erheblicher Unterschied ist!
dasselbe gilt aber auch für den UserAgent - beides
sind HTTP-Header.
EBEN NICHT!!! Der USer-Agent wird oft in Logfiles direkt
neben dem referer geschrieben, da hat man ja direkt beides
zusammen, da braucht man dann nicht mehr viel raten, daher
meine Bedenken in diese Richtung!
Der Cookie dagegen kann nur durch lauschen "abgefangen"
werden, IMHO ein erhebliche Unterschied! Oder wo werden
cookies geloggt????
Man kann Cookies auch loggen. Man kann so ziemlich alles loggen,
was der Webserver erfährt. Apache ist da sehr flexibel.

das ist wahr - aber in diesem Falle nicht relevant.

Richtig ist, daß der Betreiber eines Webservers sein Log-Format so
definieren kann, daß jeder einzelne HTTP-Header dort geloggt wird.

Was den Cookie allerdings von anderen Headern - auch dem UserAgent

• unterschiedet, das ist, daß er eben _nicht_ an _jeden_ Server
  gesendet wird, sondern nur gemäß seiner Definition (und diese kann
  und wird normalerweise so lauten, daß der Cookie nur an denjenigen
  Server zurück gesendet wird, der ihn erzeugt hat).

Insofern unterschiedet sich der Cookie tatsächlich von anderen
HTTP-Headern, weil er auf der Maschine eines Angreifers nicht an-
kommt und _deshalb_ dort nicht gelogt werden kann.

Was natürlich nicht bedeutet, daß der Cookie _nirgendwo_ geloggt
werden kann.
Er wäre beispielsweise dann zu loggen, wenn auf dem Weg zwischen
Client und Server ein Netzknoten (Proxy etc.) existiert, der unter
der Kontrolle des Angreifers steht.
_Dort_ kann _alles_ geloggt werden - auch ein Cookie.

ich gehe jetzt von dem Szenario aus, das ich mit SSL
verschlüssel. Das heißt, lauschen ist wirklich nur mit
sehr hohem Aufwand möglich, denke ich.

Aber für einen professionellen Angreifer ist auch SSL nicht
unknackbar.
Eine man-in-the-middle-Attack würde dem Angreifer möglicherweise
erlauben, sich auch in eine SSL-Kommunikation einzuklinken und
diesen Dialog "zu übernehmen", d. h. nach beiden Seiten das SSL-
Protokoll korrekt zu bedienen, aber alles mitzuschreiben (oder
sogar direkt seine eigenen Änderungen auf den Dialog anzuwenden).

Jetzt ist nur noch die Frage, ob es noch Sinn macht zu der
Session ID, die wenn möglich auch in einem cookie übertragen
wird, noch den User-Agent zu verwenden - bringt das noch
einen großen Gewinn an Sicherheit?

Gemäß Deinem Szenario, in dem der Angreifer perfekt rät, auf
welchen Informationen Dein Verfahren beruht, nein.

Ich weiß jetzt nicht wie groß sich der Aufwand eine SessionId
aus Logfiles oder wie auch immer zu bekommen, vom Aufwand die
SessionID + dazugehörigen User-Agent zu bekommen, unterscheidet.

Dieser Aufwand ist auch nicht in CPU-Ticks zu messen, sondern in
Meta-Wissen über Dein Verfahren zur Erzeugung der Session-ID.
Wenn Du dieses Verfahren offen legst, dann ist der zusätzliche
Aufwand gleich Null. Wenn nicht, dann nicht ...

get_browser() untersucht den User-Agent und zieht aufgrund dessen
Informationen aus einer lokalen Datenbank.
Damit gewinnst du nichts, sondern generalisierst.

Full ACK.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Sven,

Das ist dann aber ein schlechter Session-
Mechanismus.
Die Kombination Username/Passwort bei .htaccess
ist nicht besser. Statt einer Session-ID wird eben
diese Info übermittelt, und der Server liefert was
aus. Ist .htaccess etwa auch schlecht?

für ein Szenario, in dem HTTP-Header belauschbar sind,
ist Server Authentication nicht toll.
"Basic" ist ganz mies; "Digest" ist immerhin kopierbar,
ohne daß auf dem Server noch irgend eine Plausbibili-
tätsprüfung erfolgt (denke ich - oder?).
Bei beiden muß ein Angreifer, der lauschen kann, über-haupt nicht würfeln; von einer Session-ID erwarte ich
eigentlich mehr.

Das bietet aber keine zusätzliche Sicherheit.
Wenn der Angreifer ganz stumpf den kompletten
HTTP-Header des Browsers kopiert (was ja nicht
ausgeschlossen werden kann, vor allem, wenn dieser
Mechanismus bekannt ist - Security by Obscurity
war noch nie ein guter Ratgeber), dann kriegt er
ebenso Zugriff.

Dazu muß er aber den HTTP-Header des normalen Besu-
chers belauscht haben! Wenn er das nicht kann, dann
kann er tausend Jahre lang erfolglos Passworte würfeln.

Wie gesagt: Man kann Session-IDs raten. Man kann
Username/Paßwort raten. Wer ungestört andere eine
Million mal raten läßt, ist selber Schuld.

Eben - deshalb ist das Mitsenden von Informationen,
von denen der Angreifer gar nicht weiß, daß er sie
auch noch fälschen, d. h. auswürfeln muß, durchaus
eine Verbesserung des Verfahrens.
Die Session-ID zeigt dem Angreifer doch durch ihre
Länge immerhin die Größe des auszuwürfelnden Pass-
wort-Raums - falls jedoch weitere Anforderungen not-
wendig sind, von denen der Angreifer nichts weiß,
würfelt er automatisch falsch.

Ich denke nicht, daß zusätzliche Merkmalsprüfung
die Sicherheit wirklich qualitativ erhöht

Ich schon - allerdings nicht in beliebigen Szenarien.
Wenn der Angreifer mitlauschen kann, dann nützt so
etwas natürlich weniger.
Deshalb meinte ich ja, daß für den Aufbau einer Ver-teidigungsstrategie immer auch eine Vorstellung über
die Art des Angriffs notwendig ist.

Wer die Session-ID mittels Referrer auf seinen
Server locken kann, kriegt grundsätzlich alle
HTTP-Header des Browsers übermittelt und kann
sie zum Angriff einsetzen - wo ist da die
zusätzliche Sicherheit?

Daß er wissen muß, daß er diese Information braucht.
Er muß den Original-Request so genau nachbauen wie
möglich, weiß aber nicht, wie das geht. Und vor allem
erfährt er während seines Würfelns nicht, daß sein
Verfahren hoffnungslos ist.
Er hat keine exakte Aufgabenstellung - ginge es nur
darum, eine Session-ID zu brechen, dann hätte er eine.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Andreas,

Aber was mich erstaunt hat, htaccess Benutzerdaten
waren verschlüsselt! War Basic! Aber das war kein
Klartext, was da stand!!!

das ist BASE64-Codierung.
Die wird vermutlich nur deshalb verwendet, damit man auch exotische Sonderzeichen über alte, dumme Kommunikationsverbindungen transportieren kann, die nur 7 Bit verstehen oder was auch immer.
Jedenfalls ist eine solche Codierung reversibel, anders als MD5 - und deshalb in Sachen Sicherheit irrelevant.

Ja, aber belauschen, dann mußt Du aber auf einem
Rechner zwischendurch ein programm installieren
können, und das stelle ich mir nicht so einfach
vor! ich denke die Rechner +über die richtige
Internetverbindungen laufen, sollten doch
einigermaßen schwierig zu knacken sein, oder?

Entscheidend ist das schwächste Glied in der Kette.

Wie kann man sinnvoll verhindern, das sich jemand
mit einem Script per Bruteforce probiert
einzuloggen?

Indem man zunächst einmal Angriffe auf eine Benutzerkennung dadurch erkennt, daß mit derselben Benutzerkennung in kurzer Zeit untypisch viele Login-Versuche erfolgen. Dazu muß man alle login-Versuche
protokollieren und Plausibilitätstests realisieren.

Hat man einen Angriff erkannt, dann kann man reagieren - beispielsweise indem man die Benutzerkennung bis auf Widerruf komplett abschaltet. Das verhindert zumindest, daß ein Angreifer durch kommt - es stört natürlich möglicherweise einen Besitzer dieser Benutzerkennung beim Arbeiten. Da muß man dann halt entscheiden, was einem wichtiger ist - mir wäre es wichtiger, mein Bankkonto gegen einen Angriff geschützt zu haben, auch wenn ich während eines Angriffs ausnahmsweise mal eine Buchung per Telefon statt per Browser aufgeben muß ...

Jede Versicherung erfordert eine exakte Beschreibung
des "Schadensfalls".

Viele Grüße
      Michael

[Michael Schröpl]

Hallo Sven,

Die Brücke zwischen https und http wird AFAIK nicht geschlagen.
Wenn du auf einer https-Seite einem Link folgst, kriegt die
verlinkte http-Seite keinen Referrer übermittelt.

schlimmer noch - das Verhalten ist an dieser Stelle browserspezifisch
(weil es in HTTP nicht spezifiziert ist). Netscape 4 würde den Referrer
an dieser Stelle übermitteln - M$IE 5.0 nicht ...

Viele Grüße
      Michael

[GONZO]

Hallo artlow,

Ich möchte nur wissen, ob das mit PERL möglich ist oder ob ich in jedem Fall PHP benötige.

Natürlich geht das.
Das hat dann aber nichts mehr mit .htaccess zu tun, sondern du mußt
dann deinen eigenen "Schutz" schreiben, der mit Sessions arbeitet.
Jede Seite die du schützen willst muß sich also selber schützen.

Pseudocode an jedem Seitenanfang: (kleine Korrektur)

if( ! sesseion_etabliert)
{
 bitte_usernamen_und_passwort_eingeben
 if( user_und_passwort_gueltig)
 {
  session_etablieren
 } else {
  user_abweisen
 }
}

Dazu kommt dann noch ein mechanismus die session für beendet
zu erklären. Entweder durch timeout oder logout.

CYa
GONZO

[Sven Rautenberg]

Moin!

das ist alles richtig was du schreibst.

Mir ist es jedoch egal, ob die Daten gesavt werden oder nicht. Dann soll der User die Daten eben jedesmal neu eingeben.

Bei jedem Bild? Jeder neuen Seite? Allen sonstigen Seitenelementen? Nicht wirklich praktikabel, oder?

Andere Seiten haben das doch auch realisiert.

Wenn andere Seiten ein Login-_Formular_ haben, dann nutzen sie keinen Zugangsschutz via .htaccess, sondern etwas selbst ausgedachtes - mit allen möglichen Konsequenzen, denn sowas ist potentiell unsicherer, weil wesentlich weniger Leute sich den Code angesehen haben und Lücken finden. .htaccess ist sicher. Wenns darauf nicht so ankommt, bastel dir was eigenes.

Ich möchte nur wissen, ob das mit PERL möglich ist oder ob ich in jedem Fall PHP benötige.

Beides funktioniert. Egal ob PHP oder Perl (oder Python, C, Basic,...): Ein Programm auf dem Webserver muß die Formulardaten auswerten, entscheiden, ob der User Zugriff kriegt oder nicht, die passenden HTML-Seiten zurückliefern und sich irgendwie in Zusammenarbeit mit dem Browser merken, daß die eingegebenen Daten auch bei der nächsten Seite noch gelten.

- Sven Rautenberg

[Andreas]

Hallo!
Ich glaub da hab ich auch mal wieder was verstenden :-) Ich habe das in einem geschützten bereich mal so gemacht, das der Benutzer Seine Daten eingibt, diese per SSL übertragen werden, und auf dem Server wird dan mit Hilfe den in der DB geguckt, ob die Zugangsdaten korrekt sind. Dannach ist es aber im pribnzip direkt wieder vorbei mit der Sicherheit - ich mache das nömlich mit Sessions, da könnte man es ja schaffen, eine aktuelle SessionID zu erfahren, dann ist man drin - obwoh ich auf jeder Seite die Zugangsdaten kontrolliere, die sind aber leider in der Session(auf dem Server!!!), und nicht im Browser gespeichert. Und da liegt dann also der Unterschied. Bei htaccess wird der Browser bei jedem Aufruf überprüft, bei mir wird nur geprüft, ob der Benutzer die im Cookie oder in der URL gespeicherte SessionID gültige benutzerdaten enthält. Ist das so richtig verstanden?
Aber in der Praxis - erraten kann man die PHPSESSID wohl kaum denke ich, also müßte man entweder auf einen anderen Computer der eingeloggt ist zugreifen und hätte da die Cookiedaten, aber könnte man dann nicht genau so einfach an die htaccess Zugangsdaten, die sind ja dann auch da irgendwo gespeichert(kenne mich da aber nicht aus).
Das Andere Risiko ist wohl, wenn die Daten unverschlüsselt über Unsichere Knoten im Internet übertragen werden, das da jemand die Daten mitliest. Könnte derjenige denn wohl genauso einfach die Daten die im Cookie stehen mitlesen, genau so einfach wie das was im GET Request steht?

Viele Grüße
Andreas

PS: Erst wenn man die Schwachstellen kennt versteht man solche Sachen und kann was dagegen unternehmen!

[Cheatah]

Hi,

Dannach ist es aber im pribnzip direkt wieder vorbei mit der Sicherheit - ich mache das nömlich mit Sessions, da könnte man es ja schaffen, eine aktuelle SessionID zu erfahren, dann ist man drin

es sei denn, Du identifizierst den User nicht ausschließlich an der Session-ID. Zwar ist es natürlich nicht möglich (auch Cookies helfen bekanntermaßen nur bedingt), einen Client (oder gar User) eindeutig zu identifizieren; aber man kann hinreichend weit einschränken, indem man clientspezifische Attribute wie IP, User-Agent etc. mit abspeichert.

Bei htaccess wird der Browser bei jedem Aufruf überprüft,

Nun ja, der Browser schickt die Logindaten jedes Mal mit. "Den Browser zu prüfen" stelle ich mir anders vor ;-)

Ist das so richtig verstanden?

Grundsätzlich ja. Eine sehr klare Beschreibung der Situation.

Aber in der Praxis - erraten kann man die PHPSESSID wohl kaum denke ich,

Das denke ich auch :-)

also müßte man entweder auf einen anderen Computer der eingeloggt ist zugreifen und hätte da die Cookiedaten,

Du sagst selbst, dass die Session-ID auch in der URL stehen kann (längst nicht jeder User akzeptiert Cookies - bisweilen werden diese bereits geblockt, bevor er die Chance dazu hätte), und die ist gut sichtbar, beispielsweise in Referrer-Logs.

aber könnte man dann nicht genau so einfach an die htaccess Zugangsdaten,

Die stehen browserseitig nur im Arbeitsspeicher; praktisch betrachtet hat ausschließlich der Browser darauf Zugriff (naja, Microsoft-Systeme verschicken bei Abstürzen komplette Images des Speichers). Da Du SSL verwendest, sind die Daten bei der HTTP-Übertragung verschlüsselt, können also auch nicht ausgelesen werden. Serverseitig: Selbst wenn der Server so (fehl-)konfiguriert ist, dass die Passwortdateien (welche sich eh nicht im per HTTP zugänglichen Bereich befinden sollten) lesbar sind, sind die Passwörter (außer auf Windows-Systemen) irreversibel verschlüsselt.

Das Andere Risiko ist wohl, wenn die Daten unverschlüsselt über Unsichere Knoten im Internet übertragen werden, das da jemand die Daten mitliest. Könnte derjenige denn wohl genauso einfach die Daten die im Cookie stehen mitlesen, genau so einfach wie das was im GET Request steht?

Wenn jemand Zugriff auf die Requests und Responses hat, und wenn diese nicht von einer SSL-Schicht verschlüsselt werden, stehen ihm sämtliche kommunizierten Daten zur Verfügung.

PS: Erst wenn man die Schwachstellen kennt versteht man solche Sachen und kann was dagegen unternehmen!

Korrekt :-)

Cheatah