4. Sind meine Sessions sicher genug?

Sind meine Sessions sicher genug?

  • O

    nochwas zum thema cookies: cookies sind immer sehr unsicher,schon allein deshalb, weil sie kopiert werden können.
    alle deine sicherheitsmechanismen können umgangen werden, solange du schlüssel und alarm-geheimnummer unter der fußmatte versteckst.

    wenn du also ganz sicher gehen willst, lass die cookies raus, ansonst versuche in die cookies md5 codes,verschlüsselte zeitangaben,irgendwelche computerdaten wie browser version,windows version usw einzubauen, und vergleich die cookies dann mit den internen daten(wenn die cookie erstellungszeit nicht der der datenbank entspricht, cookie löschen, login abbrechen, warnung auf dem bildschirm ausgeben:" seit ihrem letzten besuch wurde schon von woanders auf ihren account zugegriffen, wenn sie das selber waren, müssen sie sich keine sorgen machen, ansonsten würden wir ihnen empfehlen ein neues passwort einzutragen".

    ein weiteres problem ist, dass du bruteForce attacks auf accounts abwehren können musst.

    0
  • S
    Mod

    Und was ist die Alternative zu Cookies?

    Ich glaube ihr versteht nicht, wie Cookies funktionieren... Die werden bei jeder Anfrage mitgeschickt - für einen Angreifer ist es also egal ob man die SessionID per Cookie sendet oder direkt in der URL.

    0
  • A

    otze schrieb:

    wenn du also ganz sicher gehen willst, lass die cookies raus, ansonst versuche in die cookies md5 codes,verschlüsselte zeitangaben,irgendwelche computerdaten wie browser version,windows version usw einzubauen, und vergleich die cookies dann mit den internen daten(wenn die cookie erstellungszeit nicht der der datenbank entspricht, cookie löschen, login abbrechen, warnung auf dem bildschirm ausgeben:" seit ihrem letzten besuch wurde schon von woanders auf ihren account zugegriffen, wenn sie das selber waren, müssen sie sich keine sorgen machen, ansonsten würden wir ihnen empfehlen ein neues passwort einzutragen".

    ein weiteres problem ist, dass du bruteForce attacks auf accounts abwehren können musst.

    wie bereits erwähnt habe ich mit so ziemlich allen sicherheitstechniken, die mit http (ohne s) möglich sind, gearbeitet.

    und natürlich würde ich im cookie keine plaintext daten speichern. ich würde im cookie gar keine richtigen daten speichern.

    die idee war (und es tut mir leid, habe das nicht deutlich genug beschrieben) die sessions in der datenbank zu speichern. und um sicher zu gehen, dass die anmeldung auch vom richtigen computer aus erfolgt wird beim login und beim auffrischen des cookies darin eine art prüfsumme der session gespeichert.

    so wird es sehr schwierig sein eine session zu hijacken.

    bitte um informationen zu https

    0
  • S
    Mod

    Die Daten werden Plaintext versendet - ich kann sie abfangen und an den Server schicken (und schon bin ich eingeloggt - mir ist es ja egal welche Daten es entschlüsselt sind, der Client sendet ja eh nur die verschlüsselten - und die kann ich abfangen).

    Und selbst wenn ich das aus irgendwelchen Gründen nicht kann, dann kann ich immer noch die Login Daten direkt beim Login abfangen.

    Dass eine Datenbank _praktischer_ ist als Dateien ist klar. Es ging um die _Sicherheit_ - und da ist es egal.

    0
  • A

    Shade Of Mine schrieb:

    Die Daten werden Plaintext versendet - ich kann sie abfangen und an den Server schicken (und schon bin ich eingeloggt - mir ist es ja egal welche Daten es entschlüsselt sind, der Client sendet ja eh nur die verschlüsselten - und die kann ich abfangen).

    Und selbst wenn ich das aus irgendwelchen Gründen nicht kann, dann kann ich immer noch die Login Daten direkt beim Login abfangen.

    Dass eine Datenbank _praktischer_ ist als Dateien ist klar. Es ging um die _Sicherheit_ - und da ist es egal.

    weiss schon wie http und netscape cookies funktionieren.
    habe bereits eingeräumt, dass es mehr pseudo sicherheit ist.
    gebe dir auch vollkommen recht in der hinsicht, dass es durch sniffing einfach NICHT sicher ist! je mehr man da versucht über irgendwelche umwege an ein verifizierung ranzukommen, desto mehr übersieht man die grundsätzliche unsicherheit dieses vorgehens. und zwar, dass die daten des logins im plaintext übertragen werden.

    denke können uns darauf einigen, egal wie man es dreht, es ist unsicher!

    aus diesem grund suche ich auch enie alternative!

    @Shade Of Mine:
    hast du praktische erfahrung mit https?
    wenn ja, kannst du zu meinen offenstehenden fragen (s.o.) etwas sagen?
    wäre sehr nett von dir!

    desweiteren habe ich in meiner php anwendung ein flash7 interface. dieses greift auf php scripte zu, die wiederum etwas ausgeben, das vom flash movie verarbeitet wird.

    ich werde die php scripte natürlich sichern, dh nur registrierte und angemeldete benutzer können diese scripte ausführen.
    falls man nicht zu dieser kategorie gehört, wird eine fehlermeldung im script ausgegeben, die dann im flash movie ebenfalls verarbeitet oder ausgegeben wird.

    frage dazu: wenn ich ssl einsetze und mich auf der website "bewege" wird ja die ssl session aktualisiert. nach einem bestimmten timeout, wird die session aufgelöst. das heisst, dass bei jedem laden eines scriptes, oder einer seite, die sessiondaten aktualisiert werden. werden sie auch aktualisiert, wenn ich die scripte innerhalb eines flash movies aufrufe? rechne da ehrlich gesagt nicht mit problemen. oder muss ich da doch etwas beachten?

    flash hilfe schrieb:

    Security Flash Player 7 enforces a stricter security model than previous versions of Flash Player. Exact domain matching requires that the domain of the data to be accessed match the data provider's domain exactly in order for the domains to communicate. HTTPS/HTTP restriction specifies that a SWF file using nonsecure (non-HTTPS) protocols cannot access content loaded using a secure (HTTPS) protocol, even when both are in exactly the same domain. For more information see Flash Player security features.

    0
  • S
    Mod

    alex-t schrieb:

    hast du praktische erfahrung mit https?
    wenn ja, kannst du zu meinen offenstehenden fragen (s.o.) etwas sagen?
    wäre sehr nett von dir!

    Sorry, ich bin nur Programmierer und kein Admin. Deshalb habe ich keine Ahnung wie man das installiert.

    Wenn es allerdings laeuft, dann merkt man den Unterschied nur an dem 's'. Denn der Server und Client kuemmern sich um die Verschluesselung (deshalb hast du auch etwas mehr load am Server (notfalls gibts da aber IIRC auch Hardware SSL Netzwerkkarten, die verschluesseln/entschluesseln hardwarebeschleunigt)).

    frage dazu: wenn ich ssl einsetze und mich auf der website "bewege" wird ja die ssl session aktualisiert. nach einem bestimmten timeout, wird die session aufgelöst. das heisst, dass bei jedem laden eines scriptes, oder einer seite, die sessiondaten aktualisiert werden. werden sie auch aktualisiert, wenn ich die scripte innerhalb eines flash movies aufrufe? rechne da ehrlich gesagt nicht mit problemen. oder muss ich da doch etwas beachten?

    Du musst nur darauf achten, dass die Scripte aufgerufen werden (und nicht gecasht werden). Ansonsten gibts da eigentlich keine Probleme (wobei ich Flash noch nie verwendet habe).

    0
  • A

    okay, das gibt hoffnung.

    weiter auf informationssuche.

    vielleicht interessierts jemanden, werde meine ergebnisse veröffntlichen.

    0
  • *

    hi alex-t,

    für https musst du dir ein Zertifikat/Schlüssel-Paar erzeugen und das Zertifikat signieren lassen. Das kostet beim Marktführer VeriSign über 600 Euro, billige Anbieter machen das für 145 Euro.
    Zertifikat und Schlüssel musst du beim Webserver (ich schätze Apache) einrichten.
    Die Logindaten kannst du aber auch ohne https absichern. Was du brauchst ist ein kleines JavaScript, dass md5-Verschlüsselung realisiert. Beim Login schickst du ein zufällig gewähltes Wort mit. Dieses setzt du vor oder hinter das Passwort und generierst mit dem JavaScript den Digest. Dieses verschlüsselte Passwort wird an den Server gesendet. Dieser macht genau das gleiche und vergleicht die Schlüssel einfach. Das ist nahezu nicht knackbar, da der Schlüssel jedes mal anders ist, und md5 nur mit Bruteforce zu entschlüsseln ist.

    0
  • S
    Mod

    ºgrimmsenº® schrieb:

    Die Logindaten kannst du aber auch ohne https absichern. Was du brauchst ist ein kleines JavaScript, dass md5-Verschlüsselung realisiert. Beim Login schickst du ein zufällig gewähltes Wort mit. Dieses setzt du vor oder hinter das Passwort und generierst mit dem JavaScript den Digest. Dieses verschlüsselte Passwort wird an den Server gesendet. Dieser macht genau das gleiche und vergleicht die Schlüssel einfach. Das ist nahezu nicht knackbar, da der Schlüssel jedes mal anders ist, und md5 nur mit Bruteforce zu entschlüsseln ist.

    Und was bringt das? Dann sind die Login Daten vielleicht halbwegs sicher, aber die Session kann ich immernoch ohne Probleme uebernehmen.

    Mal abgesehen davon, dass der User JS aktiviert haben muss.

    btw: woher weiss der Server denn, welches Wort zum verschluesseln verwendet wurde?

    0
  • A

    Außerdem muss das Zertifikat nicht zwingend signiert werden, soviel ich weiß. Der Benutzer bekommt dann hald eine Meldung, dass es nicht signiert ist.

    0
  • *

    @shade:
    kann man an die IP binden!

    @aj:
    dann musst du es selber signieren. Aber die Zertifikatsmafia hat genug Mechanismen gefunden um das für DAUs höchst gefährlich aussehen zu lassen.

    0
  • A

    AJ schrieb:

    Außerdem muss das Zertifikat nicht zwingend signiert werden, soviel ich weiß. Der Benutzer bekommt dann hald eine Meldung, dass es nicht signiert ist.

    eben! und solange das z.b. unternehmens intern genutzt wird, ist das doch auch voll ausreichend.

    hinzu kommt, dass confixx diese keys generieren kann, sodass man praktisch nichts zu tun muss.

    allerdings habe ich da ein problem mit.
    vielleicht kann mir hier jemand helfen. also, ich habe da nachgelesen und erfahren, dass man bei confixx dem user, der ssl nutzen soll, eine eigene ip vergeben muss. ist das richtig? oder kann man da irgendwie ein workaround machen? ich frage, weil mir einen vserver mit mehreren anderen personen teile, d.h. es gibt mehrere domains an einer ip adresse.

    ich blicke nach meiner ganzen informationssuche etwas enttäuscht. aber das kommt bei der technik ja leider zu oft vor!

    parallel dazu überlege ich mir auch non-ssl lösungen:

    wenn ich das passwort wirklich über javascript verschlüssele und dann an den login script übertrage. dort eine verifizierung stattfindet und dann entsprechend eine session starte.

    oder wenn ich in dem script, welches die user erstellt, etwa folgendes mache:

    # get url 
$url = $DOCUMENT_ROOT . dirname($PHP_SELF) . "/.htpasswd"; 
# make .htaccess and .htpasswd 
$htaccess_txt = "AuthType Basic" . "\n"; 
$htaccess_txt .= "AuthName \"".$areaname."\"" . "\n"; 
$htaccess_txt .= "AuthUserFile $url" . "\n"; 
$htaccess_txt .= "require valid-user" . "\n"; 
$htpasswd_txt .= "$user:".crypt($passwort,CRYPT_STD_DES)."\n"; 
# save files 
$htaccess= fopen(".htaccess", "w"); 
$htpasswd= fopen(".htpasswd", "w"); 
fputs($htaccess, $htaccess_txt); 
fputs($htpasswd, $htpasswd_txt); 
fclose($htaccess); 
fclose($htpasswd);

    aber natürlich alles in eine datei und mit verschiedenen usern.
    dann müsste ich aber irgendwie eine session erzeugen. denn die applikation soll benutzer management bieten.

    0
  • A

    also die applikation soll nur für eine bestimmte benutzergruppe verfügbar sein. d.h. auch, dass man dieser grupper etwa vorschreiben kann, was clientseitig installiert sein muss. z.b. der flash 7 player und js muss aktiviert sein...

    ºgrimmsenº® schrieb:

    @shade:
    kann man an die IP binden!

    @aj:
    dann musst du es selber signieren. Aber die Zertifikatsmafia hat genug Mechanismen gefunden um das für DAUs höchst gefährlich aussehen zu lassen.

    s.o.
    also, das kästchen mit "diese meldung nicht mehr anzeigen" wird angeklickt.

    Shade Of Mine schrieb:

    ºgrimmsenº® schrieb:

    Die Logindaten kannst du aber auch ohne https absichern. Was du brauchst ist ein kleines JavaScript, dass md5-Verschlüsselung realisiert. Beim Login schickst du ein zufällig gewähltes Wort mit. Dieses setzt du vor oder hinter das Passwort und generierst mit dem JavaScript den Digest. Dieses verschlüsselte Passwort wird an den Server gesendet. Dieser macht genau das gleiche und vergleicht die Schlüssel einfach. Das ist nahezu nicht knackbar, da der Schlüssel jedes mal anders ist, und md5 nur mit Bruteforce zu entschlüsseln ist.

    Und was bringt das? Dann sind die Login Daten vielleicht halbwegs sicher, aber die Session kann ich immernoch ohne Probleme uebernehmen.

    stimmt. hab jetzt im letzten post nicht darauf geachtet.
    hast etwas mehr weitblick.
    was nützt eine sichere anmeldung, wenn man die session jederzeit hijacken kann.

    also muss ich mich weiter um ssl bemühen.

    @Shade Of Mine:
    schon mal websites auf ssl sicheren servern abgeladen?
    gibt es da etwas zu beachten? ich meine nur die einrichtung der website, nicht die server konfiguration.
    im grunde ist es doch dann auch nur ein anderes (modifiziertes) protokoll, welches die daten eben verschlüsselt überträgt.
    d.h. der benutzer hat mit dem ssl nichts zu tun, sein browser handelt die verbindung aus und dann kann man sich benutzerspezifisch anmelden und sessions registrieren, diese daten sollten dann nicht mehr abgefangen werden können.

    0
  • S
    Mod

    alex-t schrieb:

    schon mal websites auf ssl sicheren servern abgeladen?
    gibt es da etwas zu beachten? ich meine nur die einrichtung der website, nicht die server konfiguration.

    Ne, du merkst den Unterschied nicht - da die ganze Arbeit der Server bei der Datenuebertragung macht.

    im grunde ist es doch dann auch nur ein anderes (modifiziertes) protokoll, welches die daten eben verschlüsselt überträgt.
    d.h. der benutzer hat mit dem ssl nichts zu tun, sein browser handelt die verbindung aus und dann kann man sich benutzerspezifisch anmelden und sessions registrieren, diese daten sollten dann nicht mehr abgefangen werden können.

    Exakt.

    0
  • A

    schön!

    und wie komme ich jetzt an ssl dran? 😞
    mit mehreren domains an einer ip adresse auf dem vserver.

    ich mache pause leute. freundin bei der arbeit besuchen und zur post fahren 😉

    bin in einer stunde wieder da. hoffe mein provider hat sich bis dahin gemeldet.

    0
  • A

    wird da vllt mal jemand wach, der mir bei ssl helfen kann? mein provider schlummert bereits.

    0
  • F

    http://www.webspace-forum.de/service/faq_d.php?link=410

    Demnach brauchst du auf jeden Fall eine eigene IP 🙄

    0
  • A

    flenders schrieb:

    http://www.webspace-forum.de/service/faq_d.php?link=410

    Demnach brauchst du auf jeden Fall eine eigene IP 🙄

    ich glaube es gibt bestimmt noch eine lösung.

    schaut euch bitte http://server.1und1.com/root_server/howto/6.html
    mal an.

    es siet sehr kompliziert aus. bin schon fleissig am überlegen. hoffe ich verstehe diese konfig bald mal.

    wenn man da nocht etwas abändert... vielleicht klappt es dann ja.

    es ist ja nicht ein mal nötig, dass domains vom ssl support ausgeschlossen werden, falls das erschwerend ist.

    es geht ja auch nicht darum die kundschaft zu beeindrucken, sondern darum sicherheit für die aplikation zu leisten.

    0
Anmelden zum Antworten