Ankündigung

Einklappen
Keine Ankündigung bisher.

Session ID zusätlzlich absichern

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Session ID zusätlzlich absichern

    Hallo Leute,

    ich bin dabei mein Login etwas zu erweitern um eine kleine Sicherheitserweiterung im Bereich der session_id.

    Ich habe ja gelesen das es möglichkeiten gibt den User Agent oder so Sachen über das Server Array an die session_id anzuhängen und damit dann zu arbeiten. Das soll aber alles nicht so unbedingt zuverlässig sein.

    Nun habe ich mir überlegt (ich habe kein Codeproblem, sondern bin da im Denkprozess), dass ich ja die session_id die vom Grund her 32 Zeichen lang ist in 4 Teile z.B. (übertrieben nur ein Beispiel) aufsplitte und an die jeweiligen Stellen zum Beispiel verschiedene Saltwerte einsetze und dann alles wieder zusammensetze und damit dann weiter arbeite. Die Saltwerte würde ich dann aller 2 Stunden neu generieren.

    Momentan hole ich mir immer beim Login und dann aller 2 Stunden via. session_regenerate_id(); eine neue Session ID.

    Was sagt Ihr dazu, wäre das ein guter Schritt um noch etwas mehr Sicherheit in der Session Geschichte?

    Vielen Dank für eure Antworten, Meinungen und eventuell sogar Verbesserungsvorschläge bzw. Denkhilfen.

    Mfg litter
    Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
    http://www.lit-web.de


  • #2
    ich verstehe garnicht vor was du die sessionid sichern willst?
    Ich kenne es eigentlich so: in der session die ip mitspeichern. Falls sich diese ändert, session löschen
    Under Construktion

    Kommentar


    • #3
      Was soll dir der Salt bringen? Wenn wer die ID klaut ists der selbe Effekt? IP mitspeichern halte ich auch für problematisch was einige ISPs oder Firmennetzwerke (?) angeht.

      Kommentar


      • #4
        Session-Klau ist immer möglich.
        Ich verstehe allerdings nicht so genau, was du da erreichen willst. Hört sich ein wenig an wie Security by Obscurity. Wenn du deine Session durch zusätzliche Hashes absichern willst, dann generiere ein zufälliges Shared-Secret/Security-Token, das nur für einen Request gültig ist. IPs haben in Sessions hingegen nichts zu suchen.
        Im Übrigen hatten wir das Thema schon oft genug, denke ich. Bitte benutze die Boardsuche.
        Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

        Kommentar


        • #5
          Du kannst deine Seite ja per https anbieten, dann kann kein Router mehr zwischen dem Client und dem Server mehr die Session-ID mitlesen.

          Aber ob du jetzt irgendwelche Salts oder Hashes noch in die Session-ID miteinbaust ist egal, solange ich die Session-ID einfach mithören kann und 1:1 wieder in einem anderem (bösen) Request verwenden kann.

          Aber in nem HTTPS-Tunnel kann niemand mithören. (So die Theorie xD)

          Kommentar


          • #6
            Bringt aber auch nichts gegen XSS oder CSRF.
            Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

            Kommentar


            • #7
              Zitat von Griffith Beitrag anzeigen
              [...]
              Aber in nem HTTPS-Tunnel kann niemand mithören. (So die Theorie xD)
              Na ja, so wirklich stimmt das auch nicht. Sondern ist eher abhängig von der gesamten Konfiguration vom Verbindungsaufbau, bis hin zur Client-Konfiguration (welche CAs dieser aktiviert hat).

              Kommentar


              • #8
                Deswegen ja auch der Zusatz: So die Theorie xD

                Kommentar


                • #9
                  Zitat von Griffith Beitrag anzeigen
                  Deswegen ja auch der Zusatz: So die Theorie xD
                  Na ja, in der Theorie kann die CA mithören, wenn Sie Lust hat. xD

                  Kommentar


                  • #10
                    Wie soll das funktionieren dass die CA mithören kann?

                    Kommentar


                    • #11
                      Zitat von Flor1an Beitrag anzeigen
                      Wie soll das funktionieren dass die CA mithören kann?
                      Nun, eine CA kann doch sehr einfach für Domain XY ein weiteres Zertifikat ausstellen, und schiebt es dann zwischen die Verbindung in Form eines MITMs, ist die CA im Browser enthalten, sollte das Wunderbar funktionieren. Natürlich könnte ja nun auch eine Root CA dazu verdonnert werden ein entsprechendes Root-Zertifikat auszustellen und weiter zu geben, damit z.B. eine Regierung (bspw. USA, denkbar wäre es) und diese könnte dann wieder Zertifikate für einzelne Domains ausstellen.
                      Aber selbst wenn das nicht so ist, bei mangelnder Valadierung des Inhabers einer Domain, entstehen hier auch Möglichkeiten.

                      Server <---- SSL ----> MITM <---- SSL ----> Opfer


                      Works as Designed.


                      Ach ja: http://files.cloudprivacy.net/ssl-mitm.pdf

                      Kommentar


                      • #12
                        Zitat von Sascha Ahlers Beitrag anzeigen
                        Nun, eine CA kann doch sehr einfach für Domain XY ein weiteres Zertifikat ausstellen, und schiebt es dann zwischen die Verbindung in Form eines MITMs, ist die CA im Browser enthalten, sollte das Wunderbar funktionieren. Natürlich könnte ja nun auch eine Root CA dazu verdonnert werden ein entsprechendes Root-Zertifikat auszustellen und weiter zu geben, damit z.B. eine Regierung (bspw. USA, denkbar wäre es) und diese könnte dann wieder Zertifikate für einzelne Domains ausstellen.
                        Aber selbst wenn das nicht so ist, bei mangelnder Valadierung des Inhabers einer Domain, entstehen hier auch Möglichkeiten.
                        Naja, es wird ja bereits seit längerem über diese Theorie und evtl auch der praktischen Umsetzung gemutmaßt! Ich würde aber sagen, dass Angriffe in der Masse auffallen würden und damit maximal gezielte Angriffe möglich wären... Ein versierter Benutzer ist aber durchaus in der Lage diese Angriffe zu erkennen!

                        Kommentar


                        • #13
                          Mh das ist ein interessanter Ansatz. Allerdings hebelt das den Grundsatz von Zertifikaten aus. Grundsätzlich muss der CA vertraut werden. Wird das Vertrauen gebrochen ist natürlich nicht mehr 100% Schutz gegeben. Von daher liegt hier der Fehler nicht im SSL Protokoll sondern eher daran das der User jemandem vertraut der aber nicht vertrauenswürdig ist.

                          Kommentar


                          • #14
                            Zitat von Sirke Beitrag anzeigen
                            [...] Ein versierter Benutzer ist aber durchaus in der Lage diese Angriffe zu erkennen!
                            Den MITM wohl, aber nicht, dass das Zertifikat gefälscht ist. Wie auch, es ist ja nicht direkt gefälscht und so lange nicht die Checksummen überprüft werden (was auf einer neu besuchten Seite nicht so einfach ist), fällt mir im Moment nichts ein.
                            Ich denke auch nicht, dass jemand dies bis zum Letzten ausnutzen wird, sondern nur bei entsprechend lohnenden Zielen. Also wirklich nur bei Einzelfällen, was hier lohnend ist, hängt natürlich vom Mithörer ab.

                            Aber auch einzelne gezielte Angriffe könnten schon zu viel sein.


                            @Flor1an:
                            Klar, aber wenn z.B. waiste Zertifikate in gut genutzten Browser auf einmal in den Nachrichten zu lesen ist, wird es schon seltsam, auch wenn dieses Beispiel nun wohl harmlos war.
                            Removing the RSA Security 1024 V3 Root at Mozilla Security Blog
                            heise open - Verwaistes Root-Zertifikat sorgt für Verwirrung

                            Kommentar

                            Lädt...
                            X