Sicheres Login

[Tom]

Hello,

Wenn du als Antwort mehr als "Nichts!" schreiben kannst, wäre das interessant.

Iiih bist Du garstig!

Denn "shtml" steht NICHT für "secure html" - das behaupten nur Betrüger-EMails, die einen zum Übermitteln der eigenen Kreditkartennummer oder irgendwelchen Passworten bewegen wollen.

Na, ist doch gut, das man hier immer wieder was lernen kann. Das bedeutet dann also, dass man für https kein ssl benöitigt?

Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler auch eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.

Falsch. Für das Anzeigen der Loginfehler-Seite ist ganz allein der Browser verantwortlich. Der kann nach 3mal den Dialog aufgeben, wenn der Browserprogrammierer es toll findet, oder auch bis zur Unendlichkeit immer wieder das Dialogfenster anzeigen und nach einem Passwort fragen - die Fehlerseite kommt dann nur, wenn man auf abbrechen klickt.

Nee, nicht falsch aber nicht vollständig. Dass der Browser für die Anzahl der Versuche zuständig ist, ist auch klar. Nun sollte ein üblicher Browser die Fehlerseite aber vom Server mit der ersten 401 übertragen bekommen und eigentlich auch anzeigen, wenn Abbruch oder Fehler auftreten. Dass es immer auch "uneigentlich" gibt, ist auch klar, oder?

Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben

Das ist vollkommen unsicher, weil jedermann durch geschicktes Hingucken ins Formular diese Art des Logins erkennen und mißbrauchen kann.

Das ist nicht unsicherer als eine Session. Der Key darf nach dem Logout nur nicht wieder verwendet werden und nicht zu kurz sein. Das ich immer noch das Zweischlüsselverfahren bevorzuge, lassen wir hier mal außen vor, ok?

Die Information, ob ein Account eingeloggt ist oder nicht, gehört nicht in die vom Browser übermittelten Daten!

Es war ja auch so zu verstehen, dass er sich auf dem Server merkt, welcher Schlüssel nun gerade als "logged in" Gültigkeit hat, wie auch immer er das macht. Das war ja noch gar nicht diskutiert worden.

Entweder wird bei jedem Request Username und Passwort übermittelt, oder eine hinreichend lange, zufällige Session-ID.

Genau, die kann er auch "im Post" übergeben, also als Hidden-Field im Formular.

Sessions mit Cookies oder Sessions mit "Auth401", also demselben Verfahren, das auch .htaccess benutzt. Leider musst Du dir diese Sessionvariante in PHP dann noch selber zusammenschrauben.

Gegen die Sessions von PHP ist aber absolut nichts einzuwenden.

Die aber eben nur mit Cookie vernünftig sind. Die Variante mit Trans_SID ist nicht glücklich. Das ist ja fast diejenige, die Thomas hier selber "erfunden" hat.

Und was steht dagegen, eine Client-Identifikation mit "Auth401" durchzuführen und trotzdem eine Session zu führen? Passwort und Loginname reichen als Sessionkennung aus. Man kann sich leider nicht abmelden.

Liebe Grüße aus http://www.braunschweig.de

Tom