Hallo,

ich will ein MiniPortal Programmieren.
Mit:
-Registrierung
-Datenbank mit Userverwaltung Passwort in MD5
-Sessionverwaltung
-usw

das ist soweit alles kein Problem. Aber ich will noch einen Automatischen Login dabei machen. Ich würde dies jetzt mit Cookies machen, ich hab aber keine ahnung wie ich das am besten mache.

meine überlegungen:

1) Username und passwort(oder md5) als cookie speichern.

nachteil: aber dann kann das cookie doch leicht kopiert werden und das ist meiner meinung nach nicht wirklich sicher.

2) bei jedem login eine zufällige md5 summe bilden diese in der datenbank(beim entsprechendem user) und in einem cookie speichern. bei jedem login währe das cookie unterschiedlich und anhand des cookies können keine dauerhaften logindaten gespeichert werden

nachteil: das cookie kann immernoch geklaut werden und einmal benutzt werden. 1 mal nutzen reicht eigentlich um das passwort zu ändern. ausserdem kann ich dann nicht mit 2 verschiedenen rechnern oder browsern das cookie benutzen. sobald ich einmal den anderen client benutzt habe ist das cookie des anderen rechners ungültig.


im moment fällt mir sonst nichts ein wie ich das evtl. sicher machen könnte.

wie wird sowas im normalfall gehandhabt?!?! was muss ich für maximale sicherheit tun? gibts noch andere möglichkeiten ausser cookie?

Mister Ad

Zergling-new

Ich würde vorschlagen username und das pw (ist ja bereits md5 hashed) jeweils in ein Cookie zu speichern und beim Autologin automatisch versuchen damit anzumelden. Somit wird das Cookie nur mit richtigem Passwort akzeptiert (ist dann sozusagen eher eine automatische Ausfüllung des Login-Formulars).
Dass das Cookie kopiert wird ist unwahrscheinlich. Entweder der User will einen Autologin weil sein PC sicher und damit auch gegen Cookie-Klau gewappnet ist (zum Beispiel weil es sein Heimrechner ist) oder er lehnt Autologin ab, dann speicherst du kein explizites Cookie.
So seh ich das

Warum so kompliziert?

Methodik 2 ist schon machbar, aber nur wenn der benutzer immer den selben client benutzt. ich denke das dies teilweise praktiziert wird. ich glaube bei iq.lycos.de wird dies so gemacht. beispiel: daheim log ich mich ein... alles klappt ganz normal. wenn ich mich dann auf der arbeit einlogge geht es ab dem zeitpunkt auf der arbeit wie eine 1. wenn ich wieder daheim bin gehts nicht mehr, erst nach einem normalen login.

Zergling-new

Der einzigste Vorteil ist doch nur, dass wenn das Cookie geklaut wird, der Dieb sich vor dem eigentlichen Besitzer damit einloggen muss, damit ihm das Cookie etwas bringt. Wenn jemand ein Cookie klaut, wird er es ja aber wohl sofort testen und den Account übernehmen.
Finde das sinnlos.

Basti

Das mag für dich gelten und auch für mich und andere hier im Forum. Aber der Großteil der normalen Web-Surfer haben keinen Einblick in die Mechanismen von Cookie-basierten Logins und die damit zusammenhängenden Risiken. Der "Normalverbraucher" denkt sich: "Fein, brauch ich das nächte mal kein Passwort eingeben" und denkt garnicht darüber nach, ob das nun auch klappt oder gar gefährlich sein könnte, wenn er diesn Gedanken im Internet-Cafe in die Tat umsetzt.

Prinzipiell würde ich so ein Auto-Login ganz ganz tief hinten in den Benutzeroptionen verstecken, in die sich nur die erfahrenen Anwender hineintrauen.

Du musst einfach bedenken, dass das Zeitfenster für jede XSS- und CSRF-Attacke auf deine Anwendung (bzw. den Benutzer) dauerhaft offen ist. Auch Session-Fixation erleichterst du auf diese Weise (falls du dich dagegen nicht anderweitig absicherst), da sich der Benutzer noch nichtmal einloggen muss, um eine ihm übergebene Session-ID seinem Konto zuzuordnen. Von daher wäre es sicher ganz gut, vor allem vor "wichtigen" Aktionen (Passwortänderungen, administrative, redaktionelle etc. Aktionen) vom Benutzer eine Passworteingabe zu fordern.

Aber ... ich würde ganz die Finger davon lassen. Du würdest doch sicherlich deine Lieferungen auch nicht einem Paketdienst anvertrauen, von dem du weißt, dass er die Päckchen einfach auf die Straße legt, wenn er den Empfänger nicht erreichen kann. Ist doch nicht zuviel verlangt, beim Öffnen der Site kurz sein Passwort einzugeben (Benutzername per Cookie voreingetragen).

Wenn du das Passwort unbedingt in den Keks schreiben willst, dann natürlich nicht im Klartext - aber auch nicht als md5-Summe, sondern verschlüsselt.

Basti

Zergling-new

Auf den Autologin verzichten? Sorry das finde ich absolut übertrieben.
Das ist wie mit deaktiviertem JavaScript, ich halte das für Paranoia. Klar kann JavaScript zum Sicherheitsproblem werden, aber mir ist es in all den Jahren noch nie passiert (ist keine Ausrede es für ungefährlich zu halten, aber die Wahrscheinlichkeit ist dann doch sehr gering).

Sicherheit ist unabdingbar, aber nicht auf Kosten der Usability.

Basti

Morgen!

Letztlich geht es immer darum, einen Kompromiss zu finden zwischen Sicherheit und Usability. Ein Auto-Login bedeutet einfach, dass jede Anfrage an die Webanwendung von einem bestimmten Rechner aus mit den Rechten des Benutzers ausgeführt wird, der sich dort diesen Auto-Login eingerichtet hat und zwar eben für den Zeitraum, für den der Auto-Login gelten soll.

Das erste Problem ist eben also, zu verhindern oder zu erschweren, dass sich der Benutzer einen Auto-Login auf einem Rechner einrichtet, über den mehrere Leute surfen, denen nicht vertraut werden kann und auf dem keine automatischen Cleanps erfolgen. Das geht letztlich nur darüber, den Benutzer eindringlich zu warnen, es ihm in dem Punkt also nicht zu einfach zu machen (Usability <-> Security).

Klar, man könnte das auch sehr differenziert implementieren, so dass das Zeitfenster erstmal klein ist und bei häufigen Logins von dem Rechner aus dieses immer mehr ausdehnen. Oder einen Keks setzen, der das speichern der Zugangsdaten unterbindet sobald ein zweiter Benutzer sich dort anmeldet (wobei das schon ein reichlich später "Schutz" wäre).

Anderen Angriffsszenarien sind durch den Auto-Login nur von daher erleichtert, dass sich ein Benutzer eben nichtmehr einloggen muss bzw. eine laufende Session haben muss, damit z.B. sein Cookie durch eine XSS-Attacke dem Angreifer zugespielt wird oder dieser eben durch eine CSRF-Attacke ungewollte Aktionen durchführen kann.

Hier liegt ein wirkungsvoller Schutz natürlich in erster Linie woanders (ggf. auch auf Kosten der Usability). Aber da sich manche Löcher nicht (ohne sehr große Einbußen in Puncto Usabilty) komplett stopfen lassen erschwert ein kleines Zeitfenster, in dem der Benutzer als solcher wiedererkannt wird die Angriffe.

Wie sicher deine Anwendung, "peterpeter" an sich schon ist/werden wird, kann dir hier natürlich niemand aus der Luft sagen. Genausowenig, wie die Ansprüche in dem Punkt definiert sind. Wenn es nur darum geht, ein paar Votings abzugeben, dann ist das alles ja womöglich eh Wurscht. Aber es würde niemand darauf kommen, in den Bereichen eCommerce, eGovernment, Online-Banking, Hosting-Backends, Free-Mailer etc. einen Auto-Login derart zu gestalten, dass ein Benutzer ohne nochmalige Bestätigung seiner Identität via direkte Zugangsdaten-Eingabe vertrauliche Daten zu Gesicht bekommt oder gar Aktionen ausführt, mit denen Geld transferiert wird etc.

Usability ist absolut wichtig. Aber in meinem Wertesystem hat der Schutz des Benutzers vor dem Missbrauch seines Vertrauens in einen Anbieter immernoch Vorrang. Was nützt eine Usability, mit der du kinderleicht und blitzschnell alle Aufgaben erledigen kannst, wenn plötzlich alle möglichen anderen Leute anfangen können, unter deinem Namen ganauso kinderleicht und blitzschnell deine Aufgaben in ihrem Sinne zu erledigen.

Basti

Zergling-new

Ich rede mehr von Communities wie dieser. Mit den von dir genannten Projekten (eCommerce (Online-Shopping aller Art), Online-Banking, ..) würde ich natürlich auch die Sicherheit viel höher ansetzen. Insofern reden wir vielleicht auch aneinander vorbei und haben andere Zielprojekte vor Augen.
Wie hast du dich denn mit dem Thema Sicherheit beschäftigt - jetzt nicht 0815 - eigene Hackererfahrung, Buch, Tutorial, oder einfach Erfahrung & Logik?

also ein autologin ist zwingend erforderlich. ich will hier nicht zu viel über mein projekt ausblaudern (zumindest nicht eh es annähernd fertig ist), aber es soll als browserstartseite verwendet werden. oder zumindest soll die option dafür gegeben sein. deswegen ist ein autologin zwingend erforderlich.

jetzt erstmal danke für die zahlreichen und ausführlichen antworten. ich werde mich jetzt wohl für cookie entscheiden. aber ein paar kleien frage habe ich noch.

1) wie verschlüssle ich das passwort am besten in einem cookie?
2) wo sollten die benutzereinstellungen (autologin ja|nein) gespeichert werden? 1. möglichkeit die einstellung userabhängig in der datenbank zu speichern. 2. möglichkeit das ganze wiederrum in ein cookie zu schreiben. vorteil des letzeren, pro client kann eine andere einstellung gewählt werden.
3) wie soll das passwort in der DB gespeichert werden? ist MD5 eine gute vorgehnsweise? gibt es bessere?


wie ich jetzt vorgehen würde:
userid und passwort(verschlüsselt) wird als cookie gespeichert, wenn das entsprechende datenbankfeld (oder cookie) gesetzt ist.
zusätzlich wird bei allen kritischen aktionen das passwort erneut abgefragt. (passwort änderung, account löschen....)

Basti

Natürlich gibt es je Anwendung unterschiedliche Ansprüche an die Sicherheit. Aber nimm mal ein Forum wie dieses hier. Angenommen der Benutzer hat die Möglichkeit, für seinen Avatar einen Link zu einem Bild anzugeben, der auch nicht weiter berprüft wird. Weiterangenommen, es gäbe einen Link Mein Benutzerkonto löschen. Jetzt braucht ein Angreifer ja nur das ganze Borad vollzuspammen und dann als Link für sein Bild eben ?action=delete_me einzugeben. Damit sind sämtliche Benutzer, die sich einen Beitrag von dir anschauen draußen.

Das funktioniert natürlich genauso, wenn die Benutzer einfach nur einen gültigen Sitzungskeks auf dem Rechner liegen haben, aber Angriffe über andere Sites oder per E-Mail sind so natürlich erleichtert. Das ist ja auch der Grnd, warum in den Links hier (z.B. Logout oben) die Session-ID explizit angehängt wird, auch wenn der Benutzer den Sitzungs-Cookie geschluckt hat.

Ich denke, man kann auch ganze Communities zumindest zeitweise lahmlegen oder Admins in den Wahnsinn treiben und damit auch großen Schaden anricht, auch wenn der Fukus vielleicht nicht darauf liegt "real life"-Vorgänge computergestützt zu realisieren (blöd ausgedrückt, aber ich glaub es ist klar, was ich meine).

[Off Topic]

Hackerfahrungen? Du meinst Crackererfahrungen, oder? Nein, die habe ich nicht. Bücher hab ich auch nicht zum Thema, wobei ich mir das neue Buch von Chris Shifflet mal näher ansehen wollte. Schlechte Erfahrungen hab ich auch selbst nicht gemacht und Logik ... ich glaube, da muss man schon ein Freak sein, um selbst auf den ganzen Mist zu kommen, der den Jungs einfällt, einem das Leben schwer zu machen. Andererseits hab ich immer die Möglichkeit von Angriffen im Kopf und so lassen sich natürlich schon Szenarien aus den (möglichen) Gegebenheiten ableiten. Aber im Netz gibt es viele Quellen dazu, auch wenn das Thema im PHP-Bereich im Allgemeinen sehr vernachlässigt wird, will ich meinen.
[/Off Topic]

Basti