Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Hacksicherer Login

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Hacksicherer Login

    Hallo Community,

    ich erstelle diesen thread da ich zu diesem Thema, hier und da draussen,
    nicht wirklich das gefunden habe, was ich eigentlich gebrauchen kann.

    Mein Ausbilder möchte von mir eine Ausarbeitung eines Hacksicheren Login haben.
    Habe da auch was geliefert, aber ihm ist das zu wenig.

    Meine vorstellung einen Hacksicheren Login zu realisieren:
    Eigene Sessionverwaltung in der Datenbank.
    Cookie mit md5-hash aus folgendem Inhalt beim Benutzer:
    md5( $sUserSessionID, $iUserID, $sUserIP );
    Mit jedem Klick wird die SessionID regeneriert
    und in der Datenbank sowie auch im Cookie gespeichert.
    Sobald die SessionID oder die IP nicht übereinstimmt, wird ausgeloggt!

    Nun meine Frage:
    Gibts da noch mehr was ich beachten muss, weil wir noch eMail-Verkehr haben?
    Wie könnte ein Hacker das knacken und wie sichere ich das noch weiter ab?


    Ich danke euch im Vorraus

    Gruß
    maller86

  • #2
    Nun ja, du könntest, das er sich überhaupt nicht einloggen kann, nach einer gewissen anzahl an Logins das Fomular für Ihn sperren... Oder so
    [B]Mfg Tomtaz[/B]
    [I]"Es soll jetzt diese Erfindung geben.... Kugel oder so heißt die. Ist so eine Art Suchmaschine..." [/I]:!::shock:

    Kommentar


    • #3
      also ich denke mal sicher ist garnix....man kann es den nur schwer machen.

      wenn ein hacker was knacke nwill dann schafft er es auch auf eine art und weise...

      Kommentar


      • #4
        Zitat von maller86 Beitrag anzeigen
        Mit jedem Klick wird die SessionID regeneriert
        Welchen Umfang hat die Aufgabe denn genau? Geht es nur um den Login-Vorgang selbst oder um die Implementierung eines geschützten Bereichs?
        • session_regenerate_id() würde ich nur direkt nach erfolgtem Login einmal anwenden.
        • Sofern es die Anforderungen zulassen, würde ich session.use_trans_sid ab- und session.use_only_cookies anschalten.
        • den IP check würde ich zwar als Standardeinstellung einschalten, aber beim Login abschaltbar für die Session machen. Es gibt immer noch Benutzer, bei denen sich die IP regelmäßig während einer Sitzung ändert.
        • sofern es die PHP Version hergibt bei [man]session_set_cookie_params[/man] httponly auf true setzen.
        • Den Ausbilder fragen, welche Form von brute-force-Sperre er bevorzugt. Die meisten davon haben mal kleinere mal größere Auswirkungen auf reguläre Benutzer.
        • für Formulare, die im weiteren Verlauf angriffssicher sein müssen, kannst Du die in http://freedom-to-tinker.com/sites/d...files/csrf.pdf beschriebene Technik verwenden. Dabei hast Du bereits einen httponly Cookie auf dem Rechner gespeichert, den Sessioncookie. Du kannst den Wert also in _SESSION speichern anstatt einen weiteren Cookie zu setzen.

        Kommentar


        • #5
          es muss doch noch was geben auf was ich nicht geachtet habe oder wovon ich nicht weiß, wenn es ihm zu wenig ist.

          Kommentar


          • #6
            Zitat von David Beitrag anzeigen
            Welchen Umfang hat die Aufgabe denn genau? Geht es nur um den Login-Vorgang selbst oder um die Implementierung eines geschützten Bereichs?
            die seite soll sicher sein, also nicht über login oder menübereich oder durch sonstwas infiltriert werden können.

            Kommentar


            • #7
              Hast Du darauf geachtet, dass alle zu schützenden Resourcen Deine Session-Verwaltung beachten?
              Hast Du Dich mit csrf beschäftigt? Das oben verlinkte PDF gibt einen Überblick.

              Was tust Du mit
              PHP-Code:
              Cookie mit md5-hash aus folgendem Inhalt beim Benutzer:
              md5$sUserSessionID$iUserID$sUserIP ); 
              bzw was machst Du dann mit den Daten?

              Kommentar


              • #8
                Ich würde die Daten auf dem Server auch nach
                md5( $sUserSessionID . $iUserID . $sUserIP );
                verschlüsseln und mit dem Cookie des eingeloggten Benutzers vergleichen.

                Wenn sich keine übereinstimmung ergibt, so wird ausgeloggt.

                //edit:
                danke für den Link, werde mir das genauer anschauen mit der PDF-Datei.

                Kommentar


                • #9
                  Was ist mit den beiden Fragen davor?

                  Das ist dann also Dein Session-Cookie? Oder ist das noch was zusätzliches? Ich sehe gerade den direkten Nutzen nicht auf Anhieb.

                  Kommentar


                  • #10
                    Zitat von David Beitrag anzeigen
                    Was ist mit den beiden Fragen davor?

                    Das ist dann also Dein Session-Cookie? Oder ist das noch was zusätzliches? Ich sehe gerade den direkten Nutzen nicht auf Anhieb.

                    Ich würde den verschlüsselten String als Cookie beim Benutzer abspeichern lassen. Wenn der Benutzer auf der Seite unterwegs ist so wird immer geprüft ob die Daten identisch sind. Durch die Sessionverwaltung in der Datenbank habe ich die einzelnen Daten zur Hand. Verschlüssele diese Daten aus der Datenbank in der gleichen Folge wie die Daten im Cookie und vergleiche diese.
                    Sobald die verschlüsselten Werte nicht gleich sind, wird ausgeloggt bzw. die Daten aus der Datenbank entfernt. Das Cookie wird zusätzlich gespeichert.

                    Hoffe es ist so verständlicher formuliert.

                    Kommentar


                    • #11
                      Ok, und warum machst Du das? Und warum machst Du das genau so. Jede Deiner Maßnahmen muss ja einen guten Grund haben, sonst ist es überflüssiger Code.
                      (Ich will mich eigentlich nicht an genau diesem Punkt festbeißen. Ich glaube zwar, dass es in dieser Form überflüssig ist und für den Fall, dass man die IP-Kontrolle abgeschaltet können soll, hinderlich. Aber es "zerstört" jetzt nicht die Sicherheit und ist deshalb nicht direkt "falsch". Wenn es einen tatsächlichen, erklärbaren Grund gibt, lasse ich mich gerne überzeugen. )


                      Was ist mit
                      Hast Du darauf geachtet, dass alle zu schützenden Resourcen Deine Session-Verwaltung beachten?
                      Hast Du Dich mit csrf beschäftigt? Das oben verlinkte PDF gibt einen Überblick.
                      ?

                      btw: md5() ist keine Verschlüsselung.

                      Kommentar


                      • #12
                        Was genau meinst du denn mit "..dass alle zu schützenden Resourcen Deine Session-Verwaltung beachten.."?
                        Die Sache ist vorerst nur eine Ausarbeitung, also davon ist noch nichts geschrieben. Aber die session_save_handler würde ich schon darauf umschreiben damit die mit der Datenbank arbeiten, wenn du das meinst. Mit csrf habe ich mich nicht beschäftigt. Die PDF werde ich mir heute Abend genauer anschauen.
                        Das mit md5, ja ^^ ich nenn es gerne verschlüsselung ^^
                        obwohl es keine ist.

                        Kommentar


                        • #13
                          Deine AOL-User werden fluchen. Die kommen nämlich bei jedem Seitenaufruf mit einer neuen IP angekrochen.
                          [PHP]if ($var != 0) {
                          $var = 0;
                          }[/PHP]

                          Kommentar


                          • #14
                            Zitat von maller86 Beitrag anzeigen
                            Was genau meinst du denn mit "..dass alle zu schützenden Resourcen Deine Session-Verwaltung beachten.."?
                            Ich meinte damit, ob irgendetwas an der Session/Login-Verwaltung "vorbei" aufgerufen werden kann.

                            PHP-Code:
                            if (!authorized()) {
                              die(
                            'xyz');
                            }
                            readfile('foo/bar.html'); 
                            Das bringt zum Beispiel rein garnichts, wenn man vom Browser aus direkt foo/bar.html aufrufen kann. Blödes, einfaches Beispiel, aber sowas in der Art.

                            Kommentar


                            • #15
                              hmm .. also ich würde es wenn dann schon so machen das die sicherheit als erstes geprüft wird und dann alles andere ausgeführt wird.
                              Sagen wir das mal so: Jeder Aufruf muss durch die index.php laufen und wenn diese nicht aufgerufen wird, lassen sich andere funktionen erst garnicht ausführen/aufrufen weil es NUR von der index.php aus laufen darf.
                              Würde also auch etwas sicherer werden

                              Kommentar

                              Lädt...
                              X