Sicherheit

[Benny-one]

sorry, eben ging bei mir php-resource nicht.

in den cookie würde ich einen timestamp und die userid sowie einen Key speichern.

ip ändert sich -> neu einloggen.
warst du eingeloggt -> 3 minuten warten.

Script läuft so ab: prüft alle 3 minuten ob du wirklich eingeloggt bist, ansonsten gilst du als logout.
wenn du insgesamt 60 min eingeloggt warst/bist, wirst du ausgeloggt und musst dich neu einloggen.

is das so in ordnung?

[mrhappiness]

Original geschrieben von Benny-one
in den cookie würde ich einen timestamp und die userid sowie einen Key speichern.

um was zu tun?

ip ändert sich -> neu einloggen.
warst du eingeloggt -> 3 minuten warten.

hm, dann könnte ich bei dir nicht tagsüber bestellen (oder was auch immer du machst), da bin ich arbeiten und selbst in der pause, wo ich dürfte, könnte ich nicht, weil ich mal den einen und mal den anderen proxy bekomme

Script läuft so ab: prüft alle 3 minuten ob du wirklich eingeloggt bist, ansonsten gilst du als logout.

wirklich? d. h. nach 3 minuten inaktivität muss ich mich nue anmelden oder was?
ich hoffe bloß, dass mein telefon nie klingelt

wenn du insgesamt 60 min eingeloggt warst/bist, wirst du ausgeloggt und musst dich neu einloggen.

warum?

[Benny-one]

Original geschrieben von mrhappiness
um was zu tun?

timestamp damit ich den user nur 60 minuten lang eingeloggt lasse. key um ihn als eingeloggt zu authentifizieren. das wäre der ersatz für die IP Abfrage.

hm, dann könnte ich bei dir nicht tagsüber bestellen (oder was auch immer du machst), da bin ich arbeiten und selbst in der pause, wo ich dürfte, könnte ich nicht, weil ich mal den einen und mal den anderen proxy bekomme

versteh ich nicht

wirklich? d. h. nach 3 minuten inaktivität muss ich mich nue anmelden oder was?

nein, du kannst ruhig das fenster offen lassen und aufs klo gehen, im hintergrund wird durch einen iframe mit refresh geprüft, ob du noch "da" bist.

ich hoffe bloß, dass mein telefon nie klingelt

versteh ich auch nicht

warum?

sicherheit....ehrlich gesagt, warum genau weiß ich nicht, ich hab das bei 1&1 gesehen und wollte es auch so machen

[mrhappiness]

Original geschrieben von Benny-one
timestamp damit ich den user nur 60 minuten lang eingeloggt lasse. key um ihn als eingeloggt zu authentifizieren. das wäre der ersatz für die IP Abfrage.

also jetzt doch nicht mit ip abfrage?
wäre es da nicht besser die daten in der session zu speichern?
wenn ich so ein cookie bei mir sehe, dann verleitet das doch geradezu dazu, den timestamp zu ändern und einfach eingeloggt zu bleiben, meinst du nicht? ich denke, es wäre besser, diese information serverseitig vorzuhalten

was speicherst du denn eigentlich in der session? oder wozu wolltest du die verwenden?

versteh ich nicht

ich dachte, du machst ne richtige abfrage der ip und ich hätte da schlechte karten, da ich nicht festlegen kann, welcher proxy denn meine anfrage wirklich an deinen server weiterleitet und sich meine ip daher schneller ändern kann als mir lieb ist

nein, du kannst ruhig das fenster offen lassen und aufs klo gehen, im hintergrund wird durch einen iframe mit refresh gepürft, ob du noch "da" bist.

dafür, dass du soviel angst vor den bösen sniffern hast, verursachst du aber mehr traffic als nötig oder?

versteh ich auch nicht

ich hab dich so verstanden, dass du mich ausloggst, wenn ich 3 minuten lang nicht irgendwo hin geklickt hab

sicherheit....ehrlich gesagt, warum genau weiß ich nicht, ich hab das bei 1&1 gesehen und wollte es auch so machen

naja, kommt drauf an was du machst

[Benny-one]

also das problem was ich habe/hatte ist:

in der session speicher ich: username, userid, password, etc.

Problem: Session wird per GET übermittelt, folgt keine IP Abfrage, so kann jeder hannes mit der gesnifften Session sich einloggen.

das problem muss ich beheben, nur wie ?

[mrhappiness]

Original geschrieben von Benny-one
Problem: Session wird per GET übermittelt, folgt keine IP Abfrage, so kann jeder hannes mit der gesnifften Session sich einloggen.

das problem muss ich beheben, nur wie ?

dann hilft dir aber das speichern eines timestamps und eines weieteren wertes in einem cookie beim client auch nicht

das zeug muss ja schließlich auch irgendwie vom client zum server kommen und wird daher automatisch mit irgendwelchen eventuell vorhandenen url-parametern einfach mitgesnifft

[Benny-one]

@happy: so bin wieder da, hab daheim pc problem gehabt.

ich hab mal bei 1&1 geguckt, die machen einfach ne SSL Verbindung und übergeben die SessionID per GET. Wenn jemand die SessionID rausbekommt kann er sich damit einloggen.

Sollte ich das auch so machen? Session + SSL?

Nur was ist, wenn jemand das System käuft und kein SSL Zertifikat hat? Dann ist es ja bedeutend einfacher, die SessionID zu sniffen und sich einzuloggen.

Hast du da eine Idee?

[mrhappiness]

machen wir's mal andersrum:

du musst einen benutzer eindeutig identifizieren können und hast folgende möglichkeiten:

1. Identifikation über eine Session und Übermittlung der Session-ID mit GET
2. Identifikation über eine Session und Übermittlung der Session-ID mit COOKIE
3. Identifikation ohne Session sondern nur über ein Cookie
4. Identifikation über die IP

Bei allen Varianten hast du die Möglichkeit, die Kommunikation per SSL zu verschlüsseln, bei dem untenstehenden gehe ich mal davon aus, dass nichts verschlüsselt wird.

zu 1.
Session-Id taucht eventuell in der Browser-History auf und wird evtl. mitgesnifft

zu 2.
Wenn du nicht alle Browserfenster der Instanz schließt, zu der auch das Fenster mit deiner Anwendung gehört hat (vorausgesetzt, du hast wenigstens das geschlossen), ist das Session-Cookie mit der Session-Id noch vorhanden und mitgesnifft werden kann's natürlich auch

zu 3.
siehe 2.
Außerdem müsstest du ja je nachdem wie du's aufziehst noch Benutzername und Passwort im Cookie speichern, die also auch immer wieder mit übertragen werden

zu 4.
Vergiss es, sonst kann von x Leuten hinter dem selben Proxy immer nur genau einer arbeiten

Egal für welche der Varianten du dich entscheidest, du musst also noch mehr tun, wie zum Beispiel:

• Ausloggen eines Benutzers nach einer definierbaren Zeit der Inaktivität
• Erneute Abfrage des Passworts an kritischen Stellen
• Session-Cookie falls vorhanden beim Schließen des Browserfensters zerstören
• sehr sauber programieren
• ...

Ach ja, bevor ich's vergesse: Du kannst zwar Kunden deines Systems dazu zwingen, SSL einzusetzen, aber erstens wirst du damit wahrscheinlich einige vor den Kopf stoßen und zweitens bringt das auch nicht unbedingt das nonplusultra an Sicherheit. Stell dir vor, du wärst Kunde und ich wäre der Proxy-Server. Dann bekomme ich (iirc) die Daten von dir unverschlüsselt und verschlüssele die erst bei mir, bevor ich sie an den Server sende. Das heißt also, dass entweder ich oder jeder andere, der sich in die Kommunikation zwischen dir und mir einklinkt, die Daten unverschlüsselt sieht. Da bräuchte es dann auch einen SSL-Proxy...

[Benny-one]

also Variante 1 und 2 kommt wohl am ehesten in Frage.

zu Variante 2: ich kann ja alle 3 Minuten prüfen, ob der User noch angemeldet bzw. aktiv ist und falls nicht kann ich ihn ausloggen.
Damit wäre doch ein Problem gelöst, oder etwa nicht?

• Ausloggen eines Benutzers nach einer definierbaren Zeit der Inaktivität

das kann ich ja mit dem 3 Minuten Rythmus feststellen.

• Erneute Abfrage des Passworts an kritischen Stellen

das mache ich bei jedem klick was der Benutzer macht

• Session-Cookie falls vorhanden beim Schließen des Browserfensters zerstören

der 3 minuten rythmus

• sehr sauber programieren

dürfte ich dir mal heute abend per E-Mail meine Klasse mit Erklärung zu deiner Einsicht senden?

Stell dir vor, du wärst Kunde und ich wäre der Proxy-Server. Dann bekomme ich (iirc) die Daten von dir unverschlüsselt und verschlüssele die erst bei mir, bevor ich sie an den Server sende. Das heißt also, dass entweder ich oder jeder andere, der sich in die Kommunikation zwischen dir und mir einklinkt, die Daten unverschlüsselt sieht. Da bräuchte es dann auch einen SSL-Proxy...

ich kann das passwort bevor es versendet wird per javascript md5 verschlüsseln -> problem gelöst - oder etwa doch nicht?

[mrhappiness]

Original geschrieben von Benny-one
zu Variante 2: ich kann ja alle 3 Minuten prüfen, ob der User noch angemeldet bzw. aktiv ist und falls nicht kann ich ihn ausloggen.
Damit wäre doch ein Problem gelöst, oder etwa nicht?

bedingt, nämlich nur, wenn er das fenster nicht schließt

• Ausloggen eines Benutzers nach einer definierbaren Zeit der Inaktivität

das kann ich ja mit dem 3 Minuten Rythmus feststellen.

s. o.

• Erneute Abfrage des Passworts an kritischen Stellen

das mache ich bei jedem klick was der Benutzer macht

bei jedem? auch auf menüpunkte? bei dir will ich nicht kunde sein, da geh ich ja tot

• Session-Cookie falls vorhanden beim Schließen des Browserfensters zerstören

der 3 minuten rythmus

und wnen ich nach zwei minuten das fenster schließe? dann wird auch dein prüf-iframe nicht mehr aktualisiert...

• sehr sauber programieren

dürfte ich dir mal heute abend per E-Mail meine Klasse mit Erklärung zu deiner Einsicht senden?

gerne

ich kann das passwort bevor es versendet wird per javascript md5 verschlüsseln -> problem gelöst - oder etwa doch nicht?

kannst du machen, aber du kannst, denke ich, niemanden zwingen, javascript zu aktivieren. vorausgesetzt, er könnte das überhaupt (sicherheitseinstellungen, ...)
also musst du leuten ohne javascript eine alternative anbieten. anderenfalls mögen dich deine kunden nicht sehr lange

um die ssl-geschihcte musst du dich ja sowieso nur dann kümmern, wenn du dich entschließen solltest, das system nur mit SSL anzubieten, anders pogramieren musst du ja nicht

[Benny-one]

bedingt, nämlich nur, wenn er das fenster nicht schließt

nein, denn im hintergrund des server würde ein cron laufen, der den timestamp prüft.
würde ein user nach 2 minuten das fenster schließen, würde der cronjob das merken das seine Zeit überschritten wurde und er wird vom system abgemeldet.

bei jedem? auch auf menüpunkte? bei dir will ich nicht kunde sein, da geh ich ja tot

naja, da gibts so ein problem, was ich dir heute abend mal erläutern möchte. Der Kunde muss das Passwort nicht immer eingeben, das system nimmt das eingegebene passwort und vergleicht es mit dem passwort in der datenbank bei jedem klick.

@md5 javascript: okay, schlechte idee, verwerfen wir das wieder.

[mrhappiness]

Original geschrieben von Benny-one
nein, denn im hintergrund des server würde ein cron laufen, der den timestamp prüft.
würde ein user nach 2 minuten das fenster schließen, würde der cronjob das merken das seine Zeit überschritten wurde und er wird vom system abgemeldet.

statt iframe?

naja, da gibts so ein problem, was ich dir heute abend mal erläutern möchte.

ich bin schon ganz gespannt

Der Kunde muss das Passwort nicht immer eingeben, das system nimmt das eingegebene passwort und vergleicht es mit dem passwort in der datenbank bei jedem klick.

klingt komisch, mir erschließt sich der mehrwert nicht

[Benny-one]

statt iframe?

nein zusätzlich. Iframe im Bereich wo sich der Kunde aufhält. Der Iframe aktualisiert sich alle 3 minuten und setzt den Zeit wert wieder hoch. im hintergrund auf dem server läuft ein Cronjob der überprüft, wo die Zeit abgelaufen ist und setzt ggf. einen User auf ausgeloggt.

klingt komisch, mir erschließt sich der mehrwert nicht

das werde ich dir anhand des codes zeigen, wo ich meine einen denkfehler zu haben.
zur not würde ich dir das auch per Telefon erklären


Jedenfalls erstmal vielen Dank, dass du dir Zeit für mich genommen hast. (war doch ganz nett das Brainstoming - mal ohne Spam *froi*)

[wahsaga]

Original geschrieben von Benny-one
Nur was ist, wenn jemand das System käuft und kein SSL Zertifikat hat? Dann ist es ja bedeutend einfacher, die SessionID zu sniffen und sich einzuloggen.

[ ] du weißt, wofür bei SSL das zertifikat dient.

[Benny-one]

Original geschrieben von wahsaga
[ ] du weißt, wofür bei SSL das zertifikat dient.

[ x ] ich weiß, wofür bei SSL das zertifikat dient.
logisch. es geht dadrum, dass jemand das System für seinen Server käuft. Der Käufer würde dann ein SSL Zertifikat benötigen, damit er wiederum seinen Kunden auch diese Sicherheit bieten kann.

falls du denkst, ich hätte gedacht, das jeder kunde ein SSL Zertifikat braucht <- schwachsinn