Ankündigung

Einklappen
Keine Ankündigung bisher.

Aktivierungscode hashen?

Einklappen

Neue Werbung 2019

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

  • Aktivierungscode hashen?

    Ich wollte mal fragen wie ihr das bisher immer gemacht habt. Wenn ihr zum Beispiel zu eurem Loginsystem auch eine Registrierung eingebaut habt und die Emailadresse verifizieren wollt. Wie generiert ihr den Aktivierungscode?

    Ich habe gedacht ich könnte vielleicht einfach die E-mailadresse hashen und als Aktivierungscode verschicken.


  • #2
    Die E-Mail-Adresse ist keine gute Idee:
    1. Ändert sich diese nie, du hast also immer den gleichen Aktivierungscode.
    2. Wenn man die E-Mail-Adresse + den Hash-Algorithmus kennt, kann man diesen leicht faken.

    Im Grunde lässt sich jeder (pseudo)zufälliger String als Aktivierungscode verwenden. Hier ein Beispiel wie es bei Sentry umgesetzt ist: https://github.com/cartalyst/sentry/.../User.php#L834

    Kommentar


    • #3
      Die E-Mail-Adresse ist sicher eine gute Idee. Wichtig ist, dass jeder Hash gesalted wird, dann hast du das Problem nicht mehr: https://crackstation.net/hashing-security.htm
      GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

      Kommentar


      • #4
        Zitat von ChristianK
        Die E-Mail-Adresse ist sicher eine gute Idee.
        In wie fern? Oder hast Du einen Konsonanten vergessen?
        Deinen Link finde ich gut, finde da aber auch keinen Bezug zu der E-Mail ( allerdings habe ich das nur überflogen ).

        Ich halte die Mail Adresse auch für schlechte Wahl.
        Wenn ich einen Aktiverungscode versende, bezieht der sich u.a. auf das bei der Registrierung angegebene Passwort.

        Was den Salt angeht, so kann man wieder ewig lang darüber diskutieren.
        Ich finde den Link von Tropi auch nicht schlecht, verstehe aber nicht, daß sich jemand ( der Author des Scripts ) scheinbar Gedanken zur Sicherheit macht, und dann für den Salt str_shuffle() verwendet, das auf rand() basiert. Zumal bei der Variante kein Zeichen mehrfach vorkommen kann, was die Anzahl der möglichen Salts deutlich ( wenn auch vernachlässigbar ) reduziert.

        Es existieren getestete Bibliotheken/Methoden, auf die man zurückgreifen sollte, wenn es um hashing geht.
        In PHP sei auf password_hash() ( ab PHP 5.5 ) und alternativ u.a. auf crypt / mcrypt hingewiesen.
        Competence-Center -> Enjoy the Informatrix
        PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

        Kommentar


        • #5
          In dem Skript, was Tropi gepostet hat, wird ja erst versucht ein String über openssl zu generieren. Die Variante, wenn Openssl nicht vorhanden ist, finde ich auch nicht sehr schön. Ist aber im Moment die beste Lösung die ich bisher gefunden habe.
          Aber da gibt es sicher noch andere Wege. Ich will vielleicht später nicht nur einen Aktivierungscode erzeugen, fällt mir im nach hinein noch ein.

          Ich könnte ja aus dem Skript den Teil mit str_shuffle nehmen und das nochmal mit mcrypt hashen. Aber ob das jetzt nötig ist weiß ich nicht.

          Kommentar


          • #6
            Zitat von Arne Drews Beitrag anzeigen
            In wie fern? Oder hast Du einen Konsonanten vergessen?
            Deinen Link finde ich gut, finde da aber auch keinen Bezug zu der E-Mail ( allerdings habe ich das nur überflogen ).

            [...]
            Ich bin der Meinung, es muss etwas sein, das sich mit dem User assoziieren lässt. Dazu eignet sich die E-Mail gut. Vermischt man das mit einem Salt spielt es so oder so keine Rolle mehr, was der Ursprungsstring war. Man könnte hier auch einen zufälligen String nehmen.

            Bezug nimmt der Artikel nicht direkt auf dieses Thema, jedoch gibt es einen guten Abschnitt über das Salzen von Passwörtern.
            GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

            Kommentar


            • #7
              Zitat von ChristianK
              Ich bin der Meinung, es muss etwas sein, das sich mit dem User assoziieren lässt.

              Ich wüsste nicht, warum ein Aktivierungscode eine Assoziation zum User haben muß, ausser natürlich die Verknüpfung zum Konto bspw. in der DB.
              Im Gegenteil, alles was sich mit dem User assoziieren lässt fördert die Unsicherheit des Vorhabens.

              Aber ich denke, darüber gibt es halt unterschiedliche Meinungen und ausreichend Diskussionen anderswo, das gehört hier vielleicht nicht her...
              Competence-Center -> Enjoy the Informatrix
              PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

              Kommentar


              • #8
                Das Problem beim reinen Hashen ist die Wiederholbarkeit. Das Problem gibt es hier aber nicht, denn die Aktivierung einer Email-Adresse muss nicht mehr als einmal gemacht werden (wenn dieser Vorgang wiederholt werden soll, dann kann man das über ein einfaches Datenbank-Flag lösen. - Im Sinne von: "Noch nicht aktiviert"). Ich sehe das genau so wie ChristianK - mit dem Unterschied, dass ich hier keinen Salt als zusätzliches Sicherheitsmerkmal sehe. Es ist völlig ausreichend, einen Hash (bestehend aus der Email-Adresse und einem nur Serverseitig gekannten Secret-String) zu generieren. Der Akivierungslink kann dann beispielsweise so aussehen (realitätsferner Konzeptcode):

                PHP-Code:
                https://www.domain.tdl/account/verify?address=<?= urlencode($email?>&code=<?= substr(md5($secret $email), 010?>
                Wenn ein User jetzt den Account aktiviert, muss man nur den Hash auf die gleiche Weise wieder erzeugen. So kann man sicherstellen, dass der Server wirklich der Urheber dieses Aktivierungslinks ist.

                Btw: Ob hier md5, sha1 oder etwas anderes verwendet wird, spielt "sicherheitstechnisch" keine Rolle. Wer das anders sieht, soll kurz mal drüber nachdenken
                Btw2: Es bleibt nach wie vor so, das sha1 und md5 nicht für die Verwendung im Zusammenhang mit Passwörtern verwendet werden sollten.
                Standards - Best Practices - AwesomePHP - Guideline für WebApps

                Kommentar


                • #9
                  Wer das anders sieht, soll kurz mal drüber nachdenken
                  dito
                  Competence-Center -> Enjoy the Informatrix
                  PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                  Kommentar


                  • #10
                    Zitat von Arne Drews Beitrag anzeigen
                    dito
                    Du kannst hier keine Methode zur Findung einer Kollision anwenden.

                    Die einzige Möglichkeit das Prinzip zu knacken ist, den Secret-String zu bekommen, in dem der Server gehackt wird. Die einzipe Möglichkeit das zu umgehen ist, den Hash aus einem starken Zufall zu erzeugen zur Email-Adresse in der Datenbank zu speichern.

                    Wenn jemand aber an den Secret-String kommt, dann hat er in aller Regel auch Zugriffsmöglichkeiten, mit denen man sich wohl einfach aktivierte Accounts anlegen kann.
                    Standards - Best Practices - AwesomePHP - Guideline für WebApps

                    Kommentar


                    • #11
                      Wir reden hier nur von einer Aktivierung! Da mag man sicher Einschränkungen akzeptieren können.
                      Jedoch lesen das hier auch Neulinge, die aus Deinen Argumenten assoziieren, daß es allgemein ein gute Lösung sei und das dann nicht nur zur Aktivierung, sondern auch für Passwörter anwenden.

                      Mir ist klar, daß Du das so nicht meinst, aber es kann so verstanden werden, davor möchte ich nur warnen.
                      Da finde ich die Links von Tropi und ChristianK schon bedeutend besser!
                      Competence-Center -> Enjoy the Informatrix
                      PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                      Kommentar


                      • #12
                        Natürlich geht es hier nicht im Passwörter. Das Prinzip ist ein völlig anderes. Aber ok. Ich habe meinen Beitrag dahingehend ergänzt.

                        Welche Einschränkungen meinst du?
                        Standards - Best Practices - AwesomePHP - Guideline für WebApps

                        Kommentar


                        • #13
                          Naja, für mich hat eine Assoziation zur Mail-Adresse des Useres im Gegensatz zu Eurer Meinung keine Sinnhaftigkeit!
                          Im Gegenteil, das senkt imho die Sicherheitsstufe dahingehend, daß ich evtl. schon mal die E-Mail Adresse kenne
                          und damit einen Bestandteil des Haswertes ( Ursprung ) habe.
                          Das empfinde ich bspw. als Einschränkung...

                          Aber da geht es wiederum um Passwörter etc. und das ist meine Meinung, keine fundamentierte Grundlage, das in diesem Thread bis ins kleinste auszudiskutieren...
                          Competence-Center -> Enjoy the Informatrix
                          PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                          Kommentar


                          • #14
                            Es geht um die Aktivierung einer Email-Adresse. Ich sehe aber nach deinem Beitrag durchaus Gefahrenpotential bei der von mir vorgestellten Lösung. Wenn man kein HTTPS verwendet, dann kann es sein, dass ein Dritter die Emailadressen mitschreiben und für unlautere Zwecke missbrauchen könnte. Bei dieser Sichtweise wäre es empfehlenswert, die Email-Adresse durch einen Surrogatschlüssel zu verklausulieren.

                            Aber lass und das Thema ruhig etwas verschärfen. Nehmen wir an, ich wende das gleiche Prinzip für die Zugänglichmachung von Bestelldaten eines Onlineshops an. Nur dass ich dann hier keine Email-Adresse als Identifikationsmerkmal habe, sondern eine Bestellnummer (die ich auch noch mal wieder maskieren könnte). Warum könnte das ein Problem sein?
                            Standards - Best Practices - AwesomePHP - Guideline für WebApps

                            Kommentar


                            • #15
                              @rkr:

                              Ich sehe keinen Grund, wieso die E-Mail-Adresse Bestandteil der Aktivierungsurl sein sollte. Das halte ich für eher unsicher.
                              GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                              Kommentar

                              Lädt...
                              X