kostenloser Webspace werbefrei: lima-city


Speichern des Loginstatus

lima-cityForumDie eigene HomepageSicherheit im Internet

  1. Autor dieses Themas

    t**k

    Hey allerseits,

    zur Zeit bin ich dabei ein Projekt zu entwickeln, wo man sich auch einloggen muss. In PHP würde ich das ganz simpel machen und einfach eine Session erstellen und da alles wichtige ablegen, aber der Haken ist, dass ich das ganze Projekt mit HTML, CSS und JavaScript mache (auf dem Server mit node.js). Bis jetzt habe ich mir das so gemacht, dass der Client bestimmte Daten für das Login benötigt (Usernamen und Hash des Passworts) und die als Cookie gespeichert. Das ist aber insofern doof, als das jeder diese Cookies auslesen kann und dadurch sich auch einen Authtoken (benötigt für spätere Sachen) generieren kann.

    Bevor ich mir jetzt da ein Sessionsystem mit Sessioncookie und einem Datenspeicher aufbaue (so ähnlich wie bei PHP, User hat nur ein Cookie mit einem Code, der Rest ist unter dem Code auf dem Server hinterlegt), wollte ich mal fragen, ob hier vielleicht jemand einen noch besseren Ansatz kennt.
  2. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

    lima-city: Gratis werbefreier Webspace für deine eigene Homepage

  3. Falls du eine Möglichkeit mit javascript suchst: Das wird nicht so einfach da Javascipt beim Client ausgeführt wird und so immer hackbar ist. Also wirst du wohl kaum um ein Serverscript herumkommen. Hier ein Paar anregungen.

    PHP
    .htaccess
  4. Autor dieses Themas

    t**k

    nilsmargotti schrieb:
    Falls du eine Möglichkeit mit javascript suchst: Das wird nicht so einfach da Javascipt beim Client ausgeführt wird und so immer hackbar ist. Also wirst du wohl kaum um ein Serverscript herumkommen. Hier ein Paar anregungen.

    PHP
    .htaccess


    Mit JavaScript ist das kein Problem, durch node.js wird das als Serveranwendung ausgeführt und ist somit "sicher" vor Veränderungen.
    Die Daten in den Cookies dienen im Endeffekt eh nur der Wiedererkennung des Users bei einem Reload der Seite. Nur da ist im Moment die größte Gefahr. Ich stelle so etwas wie eine API für die Webanwendung, und in den Cookies werden alle wichtigen Daten gespeichert, die man zum Authenfizieren braucht. Ich weiß, dass das nicht sicher ist und werde wahrscheinlich ein Sessionsystem für mich implementieren, aber habe da immer noch das Problem, dass ich irgendwie speichern muss, welche Session der Client hat und der Client auch eben die ID wissen muss, in PHP wird das zum Beispiel über einen Cookie geregelt, aber den könnte man auch klauen.
    Darum frage ich hier, ob jemand da vielleicht eine gute Idee hat. Muss es ja eh selbst implementieren.
  5. Speichere keine Login-Daten mit dem Browser,
    das ist sehr unsicher!
  6. Autor dieses Themas

    t**k

    destysoft schrieb:
    Speichere keine Login-Daten mit dem Browser,
    das ist sehr unsicher!


    Ach ne, soweit ist mir das auch klar.
    Deswegen ja das Sessionsystem, welches ich implementieren werde. Die Frage stellt sich nach dem wie, also wie mache ich das möglichst von Anfang an sicher, welches Backend und der ganze Spaß...
  7. Wenn du ganz sicher gehen willst: Eigenes Backend, dass du autorisierende Nutze (also DU) kennen. Ein Sessionsystem ist bisher das sicherste für mich persönlich, da es Browser- und Sitzungsabhängig ist, Zudem ist die Sitzung meist an der IP gebunden - sofern du es so entwickelst!
  8. Autor dieses Themas

    t**k

    kuschellea31 schrieb:
    Wenn du ganz sicher gehen willst: Eigenes Backend, dass du autorisierende Nutze (also DU) kennen. Ein Sessionsystem ist bisher das sicherste für mich persönlich, da es Browser- und Sitzungsabhängig ist, Zudem ist die Sitzung meist an der IP gebunden - sofern du es so entwickelst!


    Dem ersten entnehme ich, dass es sicherer ist, wenn ich etwas völlig eigenes benutze. Dem muss ich aber wiedersprechen. Zum Beispiel ist es sinnlos, ein Datenbanksystem, wie z. B. MySQL, zu entwickeln, wenn so etwas schon vorhanden ist und auch von vielen genutzt wird und zeitnah mit Updates versorgt wird, nur damit man selbst was hat, was keiner kennt. Bei Projekten mit großer Nutzerbasis ist es so, dass sich viel mehr Leute damit beschäftigen und deswegen auch schneller Fehler gefunden werden. (OK, MySQL ist hier ein schlechtes Beispiel, wegen Oracle, aber hoffe es ist klar geworden, was ich meine.)
    Wenn du meinst, ich soll eine eigene Sessionverwaltung/-ablage machen, hab ich das sowieso vor, da ich bis jetzt keine gute Lösung dafür gefunden habe.

    An die IP wollte ich das nicht binden (höchstens bei IPv6), da eigentlich jeder eine dynamische Adresse besitzt und damit es eher zu Problemen führt.
  9. Hallo,

    warum sollte die IP-Session zu Problemen führen? Man kann sich noch immer mit einer anderen IP ein zweites mal anmelden. Die alte Sitzung würde dann nach Beispielsweise 15 Minuten (jenachdem wie lange du die Sitzung aufrechterhalten möchtest) vom Server geschlossen / beendet werden. Ich meinte eher, dass die vom Benutzer gestartete aktuelle Sitzung an die aktuelle IP vom Benutzer gebunden wird, nicht, dass der Benutzer für immer an ein und die selbe IP gebunden wird. Die meisten Webseiten wie www.sony.de oder http://de.playstation.com nutzen dies, um deren Nutze vor Hacking zu schützen. (Mir ist zwar nicht klar "wie" man es bei SSL hacken soll ... aber egal :D)

    Beitrag zuletzt geändert: 9.5.2013 15:46:38 von kuschellea31
  10. Autor dieses Themas

    t**k

    kuschellea31 schrieb:
    Hallo,

    warum sollte die IP-Session zu Problemen führen? Man kann sich noch immer mit einer anderen IP ein zweites mal anmelden. Die alte Sitzung würde dann nach Beispielsweise 15 Minuten (jenachdem wie lange du die Sitzung aufrechterhalten möchtest) vom Server geschlossen / beendet werden. Ich meinte eher, dass die vom Benutzer gestartete aktuelle Sitzung an die aktuelle IP vom Benutzer gebunden wird, nicht, dass der Benutzer für immer an ein und die selbe IP gebunden wird.

    Das hatte ich auch nciht so verstanden, mir war schon klar, dass man nur die eigentliche Session an die IP bindet. Die Sache ist trotzdem ja, dass ich nicht will, dass sich der Benutzer bei IP-Wechsel neu anmelden muss. Ich sehe in sowas nur eine begrenzte Sicherheit oder eher noch unsicherheit, wenn man sich mit auf eine dynamisch vergebene IP verlässt. An für sich ist das Problem erstmal nur, dass ich merke, ob ich den Nutzer schon kenne und der sich schon mit dem Browser angemeldet hat, falls dieser mal die Seite neuladen sollte, der Rest der Daten wird eh vom Server dann abgerufen.
    Dabei soll die Speicherung der Session möglichst sicher geschehen, also dass es nicht so einfach ist, diese zu stehlen.
    In PHP würde ich zum Beispiel eine Session starten und dann bei jedem Reload die ID neu generieren.
    Das könnte ich mit node.js auch implementieren (oder eher im Zusammenspiel von node.js und der Webanwendung), aber mir fällt da im Moment kein sinnvoller Weg ein, die Daten abzulegen, also auf Server und Client. Auf dem Client wäre das einfachste einen Cookie zu erstellen, aber dieser könnte dann schon wieder ziemlich simpel ausgelesen werden und wenn man es eh implementieren muss, dachte ich mir, kann ich mal fragen, was andere da so für Ideen haben.
    Für den Server habe ich auch noch keine richtige Lösung, aber da sehe ich das geringste Problem.
  11. Wegen der IP-Session brauchst du dir keine Sorgen machen, die Deutschen Internetanbieter sind dazu verpflichtet, sollte jemand anderes zuvor die IP haben, mindeststens 6 Stunden Abstand zwischen der neuzuweisung der IP zu lassen. Diese IP wird dann erst nach 6 Stunden neu vergeben, denn der Anbieter kann ja nicht wissen, ob und wo diese IP noch angemeldet ist.

    Mir ist gerade noch eine andere Idee eingefallen: Du kannst die Sessions auch in der MySQL speichern. An diese Daten wird ohnehin niemand herankommen, da meistens nur der localhost (Der Server selbst) in der my.ini vom MySQL-Server zugelassen wird. Externe Verbindungen sind ohnehin nicht möglich, somit wäre es doch eine sichere Idee, oder nicht?

    Beitrag zuletzt geändert: 9.5.2013 22:34:12 von kuschellea31
  12. Autor dieses Themas

    t**k

    kuschellea31 schrieb:
    Wegen der IP-Session brauchst du dir keine Sorgen machen, die Deutschen Internetanbieter sind dazu verpflichtet, sollte jemand anderes zuvor die IP haben, mindeststens 6 Stunden Abstand zwischen der neuzuweisung der IP zu lassen. Diese IP wird dann erst nach 6 Stunden neu vergeben, denn der Anbieter kann ja nicht wissen, ob und wo diese IP noch angemeldet ist.

    Naja, 6h ist nicht sehr viel jetzt, wenn man einen Loginstatus speichern möchte... Aber egal, IP höchstens als optionale Verifikation, nicht als pflichtkriterium zur Überprüfung (z. B. wenn jemand hinter einem Anonymisierungsdienst sitzt, könnte das auch zu Problemen führen).

    kuschellea31 schrieb:
    Mir ist gerade noch eine andere Idee eingefallen: Du kannst die Sessions auch in der MySQL speichern. An diese Daten wird ohnehin niemand herankommen, da meistens nur der localhost (Der Server selbst) in der my.ini vom MySQL-Server zugelassen wird. Externe Verbindungen sind ohnehin nicht möglich, somit wäre es doch eine sichere Idee, oder nicht?

    Wie schon gesagt, Server sehe ich als geringstes Problem, wobei ich da eher eine nicht relationale Datenbank einer relationalen vorziehen würde.

    Aber das Problem liegt immer noch beim Client. Speichere ich da die Session z. B. in einem Cookie, kann jeder dahergelaufe Bot diesen auslesen und damit die Session kapern, dass ist das, was mir Sorge bereitet.
  13. h**s

    du könntest das ganze ja so anlegen das es gar keinen fortwährenden session-code gibt den du im cookie ablegst, sondern immer nur ein token-code der immer nur einmal gültig ist und bei jedem aufruf (oder sagen wir bei ner persistenten nodejs verbindung pro aktion) neu generiert (und im cookie und der datenbank abgelegt) wird - dazu eine begrenzte lifetime für diesen token-code und du bist meiner meinung nach auf der etwas sichereren seite bezüglich spybots...
  14. Autor dieses Themas

    t**k

    hcms schrieb:
    du könntest das ganze ja so anlegen das es gar keinen fortwährenden session-code gibt den du im cookie ablegst, sondern immer nur ein token-code der immer nur einmal gültig ist und bei jedem aufruf (oder sagen wir bei ner persistenten nodejs verbindung pro aktion) neu generiert (und im cookie und der datenbank abgelegt) wird - dazu eine begrenzte lifetime für diesen token-code und du bist meiner meinung nach auf der etwas sichereren seite bezüglich spybots...

    Das hört sich sinnvoll an, werde mal versuchen, dass zu implementieren.
  15. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

    lima-city: Gratis werbefreier Webspace für deine eigene Homepage

Dir gefällt dieses Thema?

Über lima-city

Login zum Webhosting ohne Werbung!