Login - wie sicher?

[Tomy]

Hi!

Ich würde gerne wissen wollen, wie sicher die im Folgenden beschriebene Loginprozedur ist:

Über ein Formular wird der Benutzername und das Passwort eingelesen und per POST an eine Datei übergeben.
Diese codiert das Passwort mit md5() und prüft, ob es mit dem Benutzernamen in einer Datei (Passwort ebenfalls verschlüsselt) übereinstimmt.
Wenn ja, wird auf eine geschützte Seite weitergeleitet.

Ist diese Prozedur leicht zu knacken?
Gibt es eine sicherere Möglichkeit (ohne .htaccess)?

Ich hoffe, ihr könnt mir helfen!

Tomy

[Ludger]

Hi,

Ist diese Prozedur leicht zu knacken?

noee, eigentlich kaum. Gut, dass es ein POST ist und kein GET. Wenn die "geschuetzte Seite" nur so erreichbar gemacht wird, dann ist das OK.

Noch sicherer waere es allerdings per SSL. Dann kann auch nicht "mitgelauscht" werden.

Gruss,
Ludger

[Tomy]

Ah, ok! Danke!
Dann bin ich beruhigt... ;-)

[Eternius]

Hallo,

http://www.google.de/search?q=man+in+the+middle+attack
http://de.wikipedia.org/wiki/Surjektiv

gruss
--
no strict;
no warnings;

awesome, awesome to the max

[dedlfix]

Wenn ja, wird auf eine geschützte Seite weitergeleitet.

Definiere "geschützte Seite". Wenn du "weiterleitest" interpretiere ich das so, dass man auch direkt diese Seite aufrufen kann.

Was spricht gegen .htaccess?

Wenn du .htaccess nicht verwenden kannst, schau dir mal HTTP-Authentifizierung mit PHP an.

Die User-Prüfung muss auf der Seite stattfinden, die angezeigt (oder eben nicht) werden soll.

[Tomy]

Definiere "geschützte Seite". Wenn du "weiterleitest" interpretiere ich das so, dass man auch direkt diese Seite aufrufen kann.

Ja, man kann zwar die Seite direkt aufrufen, aber am Anfang der Datei wird erst geprüft, ob ein Passwort korrekt eingegeben wurde.

Was spricht gegen .htaccess?

Mit htaccess hab ich bisher immer gearbeitet...
Ich möchte aber gerne eine Eingabemaske direkt auf der Seite haben, und das geht so weit ich weiß nicht damit.

[Christoph Zurnieden]

Hi,

Was spricht gegen .htaccess?

Mit htaccess hab ich bisher immer gearbeitet...
Ich möchte aber gerne eine Eingabemaske direkt auf der Seite haben, und das geht so weit ich weiß nicht damit.

Es mag einige Gründe geben, dem Nutzer seine gewohnten Werkzeuge wegzunehmen und durch Selbstgestricktes zu ersetzen. "Geht so nicht direkt auf der Seite" ist keiner.
Also verrate doch mal: warum möchtest Du das wirklich?

so short

Christoph Zurnieden

[Tomy]

Also verrate doch mal: warum möchtest Du das wirklich?

Ich wüsste nicht, warum ich hier etwas falsches posten sollte...
Ich finde die .htaccess-Methode "unedel".
Wenn die Lösung so gut wäre, warum würden dann beispielsweise alle großen Internetanbieter wie 1&1, Telekom etc. nicht darauf bauen?
Außerdem soll die Login-Prozedur erstmal nur für mich sein, um die Seite zu administrieren...

[dedlfix]

Ich wüsste nicht, warum ich hier etwas falsches posten sollte...

Falsch ist es erstmal nicht, aber meiner Meinung nach auch nicht das beste Lösung.

Ich finde die .htaccess-Methode "unedel".

Es sind also "nur" optische Gründe. Die Optik ist aber nur ein Aspekt vom Ganzen. Du solltest nicht die Bewährtheit von Standards und deren Benutzbarkeit der Optik zuliebe opfern.

Bedenke bitte folgendes:

Mit HTTP-Authentifizierung hast du eine getestete und standardisierte Login-Methode. Diverse Browser bieten dafür sogar dem Benutzer die Möglichkeit diesen Login-Vorgang zu automatisieren. Der Nutzer hat davon also einen Vorteil.

Wenn du für das Login was eingenes Strickst, kannst du das zwar wunderschön an das Design deiner Seite anpassen, nimmst damit aber dem Benutzer die Möglichkeit der automatisierten Anmeldung.
Okay, manche Browser erkennen auch solche Login-Methoden und bieten da auch eine Eingabe-Unterstützung an, da das aber jeder Webseitenbetreiber machen kann, wie er denkt, bleibt es für die Browser und die Nutzer immer eine Glückssache ob diese Hilfmechanismen funktionieren oder nicht.

Als weiterer Faktor kommt noch hinzu hinzu, dass du bei mehreren Seiten jede einzelne extra schützen musst (okay, das kann man auch per Include in jede Datei einbinden). Dazu brauchst du aber weitere Dinge: Sessions, Session-IDs, Cookies, ... und holst dir damit noch mehr Komplexität und Fehlerquellen ins Haus.

Deine Benutzer werden die Qualität deiner Seite nicht primär von der Login-Prozedur abhängig machen. Die kommt nur einmal am Anfang ganz kurz.

Wenn die Lösung so gut wäre, warum würden dann beispielsweise alle großen Internetanbieter wie 1&1, Telekom etc. nicht darauf bauen?

Hier sitzen nicht unbedingt immer Menschen mit genügend Sachverstand an den Entscheidungshebeln.

Außerdem soll die Login-Prozedur erstmal nur für mich sein, um die Seite zu administrieren...

Am Ende kannst du eh machen was du willst, ich will dir da nichts vorschreiben, nur den einen oder anderen Denkanstoß geben.

Setz dein Vorhaben ruhig in die Tat um, teste es auf Herz und Nieren, versuche es auszutricksen, erkunde Vor- und Nachteile, und dann entscheide, ob sich der Aufwand lohnt.

[wahsaga]

hi,

Ich finde die .htaccess-Methode "unedel".
Wenn die Lösung so gut wäre, warum würden dann beispielsweise alle großen Internetanbieter wie 1&1, Telekom etc. nicht darauf bauen?

warum baut beispielsweise das heise-forum darauf?

(u.a.)

gruß,
wahsaga

[MudGuard]

Hi,

Ich finde die .htaccess-Methode "unedel".
Wenn die Lösung so gut wäre, warum würden dann beispielsweise alle großen Internetanbieter wie 1&1, Telekom etc. nicht darauf bauen?
warum baut beispielsweise das heise-forum darauf?

Oder das hier natürlich vollkommen unbekannte Self-Forum ... ;-)

cu,
Andreas

[RFZ]

warum baut beispielsweise das heise-forum darauf?

Bedenke aber auch, dass HTTP-Auth bei jedem Seitenaufruf unverschlüsselt Passwort und Benutzername mitsendet. Bei Sessions etc. ist das nicht nötig.
Falls also wirklich jemand 'mithört' ist HTTP-Auth deutlich unsicherer...

greetz RFZ

[Henryk Plötz]

Moin,

Bedenke aber auch, dass HTTP-Auth bei jedem Seitenaufruf unverschlüsselt Passwort und Benutzername mitsendet. Bei Sessions etc. ist das nicht nötig.
Falls also wirklich jemand 'mithört' ist HTTP-Auth deutlich unsicherer...

Jain, falls jemand mithört ist die Sicherheit von Basic Auth der von Sessions in etwa gleichwertig da bei Sessions das Passwort mindestens einmal unverschlüsselt durchgeht und später immer wieder die Session-ID. (Alles natürlich unter der Vorraussetzung, dass kein SSL benutzt wird.)

Allerdings ist HTTP Authentication nicht gleich HTTP Authentication: Das beschriebene gilt nur für Basic Auth. Es gibt allerlei alternative Authentifizierungsmechanismen die dieses Problem nicht haben, aber ohne SSL auskommen: Schön standardisiert zum Beispiel Digest. Oder Microsoft- bzw. Windows-spezifisch NTLM oder Kerberos (läuft mir unverständlicherweise unter "Negotiate"). (NTLM wird neuerdings sogar nicht nur vom IE gemacht, sondern etwa auch von Mozilla, aber das Protokoll ist furchtbar krank.)

[Tom]

Hello,

warum baut beispielsweise das heise-forum darauf?
Bedenke aber auch, dass HTTP-Auth bei jedem Seitenaufruf unverschlüsselt Passwort und Benutzername mitsendet. Bei Sessions etc. ist das nicht nötig.
Falls also wirklich jemand 'mithört' ist HTTP-Auth deutlich unsicherer...

Und HTTP-Auth kennt keine "Abmeldung vom System". Es handelt sich bei HTTP ja auch nicht um ein Login-Verfahren, sondern nur um ein Re-AUTH-Verfahren. Das ist eben ein Unterscheid.

Bei Verwendung von Zertifikaten (Session-Cookies) könnten diese auch während der Session neu gesetzt werden, was die Sicherheit erhöht.

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

Tom

[Dennis]

Hi Tomy,

Ja, man kann zwar die Seite direkt aufrufen, aber am Anfang der Datei wird erst geprüft, ob ein Passwort korrekt eingegeben wurde.

Du hast natürlich auch darauf geachtet, dass dein Script sicher ist, falls auf dem Server register_globals=on gesetzt sein sollte?
Die Passwort-Datei ist natürlich nicht von außen abrufbar (liegt z.B. außerhalb des DocumentRoots)?

MfG, Dennis.

[Tom]

Hello,

Was spricht gegen .htaccess?

Mit htaccess hab ich bisher immer gearbeitet...
Ich möchte aber gerne eine Eingabemaske direkt auf der Seite haben, und das geht so weit ich weiß nicht damit.

Das Verfahren ist ja auch ähnlich. Es ist nur vom Webserver in die Applikation hinein verschoben. Es muss nun also jedes Script eigenständig die Berechntigung prüfen, und das den gesamten Baum entlang.

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

Tom

[Tom]

Hello,

Definiere "geschützte Seite". Wenn du "weiterleitest" interpretiere ich das so, dass man auch direkt diese Seite aufrufen kann.

Das ist ja prinzipiell nichts Schlimmes.
Wenn das System objektorientiert arbeitet (hat nichts mit oo Programmiersprache zu tun), dann weiß das Script doch selber, wie es sich schützen muss. Und wenn dann bei der Weiterleitung kein gültiges Zertifikat mitgesendet wird, weist es die weitere Bearbeitung des Requests eben ab.

Letztlich funktionieren die ganzen Session-basierten Systeme so.

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

Tom

[Andreas Lindig]

Hallo,

Wenn ja, wird auf eine geschützte Seite weitergeleitet.

bedenke nur, daß Du dann eine Session brauchst, um den "loginZustand" auf anderen Seiten aufrecht zu erhalten, gell?

Gruß, Andreas