Ankündigung

Einklappen
Keine Ankündigung bisher.

Sicheres verschlüsseln mit mcrypt?

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von t.animal Beitrag anzeigen
    Ja. Das leuchtet mir ein. Soll ich dann Passwörter die zu kurz sind also besser durch Wiederholung auf die richtige länge bringen?
    "Passwort abgelehnt. Ihr Passwort ist verdammt noch mal zu kurz, zu billig und zu doof. Geben Sie sofort ein besseres Passwort an. Anderenfalls löscht sich diese Software in 2 Minuten von selbst. Hinweise zu sicheren Passwörtern finden sie hier: <link>.
    Klicken Sie hier: <link>, um ein zufälliges, sicheres Passwort erstellen zu lassen".

    Kommentar


    • #17
      Bitte bitte bitte keine Hashing oder Kennwortalgorithmen mischen. Anstelle der (erwarteten) höheren Sicherheit erhöht sich die Gefahr durch Schwachstellen zweier eingesetzter Mathematischer Algorithmen enorm.

      Beim Hashen werden die Kennwörter ja nicht verschlüsselt sondern es werden Prüfsummen gebildet. Je mehr Schwachstellen das ganze jetzt hat (und seien es nur die von MD5 und SHA1 zusammen) desto mehr Angriffsmöglichkeiten für Kollisionen gibt es später auch.

      Das ist definitiv nicht sicherer sondern eher im wesentlichen unsicherer.

      Kommentar


      • #18
        Zitat von t.animal Beitrag anzeigen
        Ja. Das leuchtet mir ein. Soll ich dann Passwörter die zu kurz sind also besser durch Wiederholung auf die richtige länge bringen?
        Hi,

        Was soll das bringen? User gibt als Passwort abc an und du verlängerst es nun auf abcabc. Jetzt gibt nun der Hacker das Passwort abc ein und ist drin, da es auch auf abcabc verlängert wird. Willst du aber dem User das veränderte Passwort mitteilen, damit er das längere benutzen muss, dann kannst du ihm auch gleich sagen, er soll ein vernünftiges Passwort erstellen oder ein zufälliges sichereres Passwort erstellen.

        Gruß Thomas

        Kommentar


        • #19
          könnest du ein sicheres password zu erstellen immer ein salt (nennt man so?) hinten dranhänhen, also zb: password+"$s344j3§" ... dann sieht schonmal backups von der db "knacksicherer"...
          die einfachste methode wäre dich das pw 2 x per MD5() zu "verschlüsseln"...
          Under Construktion

          Kommentar


          • #20
            Zitat von Hu5eL Beitrag anzeigen
            die einfachste methode wäre dich das pw 2 x per MD5() zu "verschlüsseln"...
            Wie ist das gemeint?

            Kommentar


            • #21
              Zitat von pacey Beitrag anzeigen
              Bitte bitte bitte keine Hashing oder Kennwortalgorithmen mischen. Anstelle der (erwarteten) höheren Sicherheit erhöht sich die Gefahr durch Schwachstellen zweier eingesetzter Mathematischer Algorithmen enorm.
              Gut. Wenn wir evtl. Fehler im Hash-Algorithmus mal außer acht lassen, würde die Sicherheit des verschlüsselten Parts durch folgende Aktion steigen (abgesehen natürlich von Brute-Force, s.u.)?
              PHP-Code:
              $keyhash('sha512''Password'true);
              //$Key = æÈ;(*ë.(DYW!Ì�»ÚGË$S|yù»„ð@9ágnk¨W>X¡%㪠2©åXy®"°ÂÖ!6ü >…ø» 
              Zitat von Thomas Beitrag anzeigen
              Hi,

              Was soll das bringen? User gibt als Passwort abc an und du verlängerst es nun auf abcabc. Jetzt gibt nun der Hacker das Passwort abc ein und ist drin, da es auch auf abcabc verlängert wird. Willst du aber dem User das veränderte Passwort mitteilen, damit er das längere benutzen muss, dann kannst du ihm auch gleich sagen, er soll ein vernünftiges Passwort erstellen oder ein zufälliges sichereres Passwort erstellen.

              Gruß Thomas
              Ich dachte daran, dem User nicht mitzuteilen,dass sein Passwort verlängert wird. Verwendet er abc rechne ich intern mit abcabc. verwendet er abcdefg verwende ich eben abcdefg. Verwendet er mehr als 32 Zeichen (ÜPHP: mcrypt_enc_get_supported_key_sizes - Manual), dann muss ich eben beschneiden.

              Zitat von Hu5eL Beitrag anzeigen
              könnest du ein sicheres password zu erstellen immer ein salt (nennt man so?) hinten dranhänhen, also zb: password+"$s344j3§" ... dann sieht schonmal backups von der db "knacksicherer"...
              die einfachste methode wäre dich das pw 2 x per MD5() zu "verschlüsseln"...
              Das ist imho nicht richtig. S.: PHP: mcrypt_module_open - Manual

              Zum Thema Salt: Salts bringen's doch nur dann, wenn ich sie nicht gemeinsam mit dem Nutzernamen speichere, oder? Und wie soll ich das bewerkstelligen?

              PS: Verdammt, wie machen die Jungs von TrueCrypt das denn?

              Kommentar


              • #22
                Zitat von t.animal Beitrag anzeigen
                Gut. Wenn wir evtl. Fehler im Hash-Algorithmus mal außer acht lassen, würde die Sicherheit des verschlüsselten Parts durch folgende Aktion steigen (abgesehen natürlich von Brute-Force, s.u.)?
                PHP-Code:
                $keyhash('sha512''Password'true);
                //$Key = æÈ;(*ë.(DYW!Ì�»ÚGË$S|yù»„ð@9ágnk¨W>X¡%㪠2©åXy®"°ÂÖ!6ü >…ø» 
                Ja und nein. Ja, wenn Du nur den hash speicherst und Dein System irgendwo ein Leck hat (zum Beispiel sql inject vulnerability) wird `nur´ der Hash des Passwortes bekannt. Bei einem hinreichend sicheren Hashalgorithmus ist das Passwort nicht sofort kompromittiert. Nein, es macht aus einem `dummen´ Passwort keine sichere Sache. Wenn der Benutzer bei Deinem "mindestens sechs Zeichen"-Passwortsystem aaaaaa oder 123456 wählt, wird daraus durch hash('sha512', $userinput, true) kein besseres Passwort.

                Salt muss erkennbar und im Klartext mit gespeichert werden, sonst kannst Du keinen vergleichbaren Hash aus der Klartexteingabe erstellen. Es dient nur gegen Rainbow-Tables und der Verschleierung gleicher Passwörter verschiedener Benutzer.

                Kommentar


                • #23
                  Zitat von David Beitrag anzeigen
                  Ja und nein. Ja, wenn Du nur den hash speicherst und Dein System irgendwo ein Leck hat (zum Beispiel sql inject vulnerability) wird `nur´ der Hash des Passwortes bekannt. Bei einem hinreichend sicheren Hashalgorithmus ist das Passwort nicht sofort kompromittiert. Nein, es macht aus einem `dummen´ Passwort keine sichere Sache. Wenn der Benutzer bei Deinem "mindestens sechs Zeichen"-Passwortsystem aaaaaa oder 123456 wählt, wird daraus durch hash('sha512', $userinput, true) kein besseres Passwort.
                  Warum nicht? Geht es dir nur um brute force-Angelegenheiten? Angenommen die verschlüsselten Daten lecken ins Netz. Wäre es dann nicht schwerer, den Text der mit "æÈ;(*ë.(DYW!Ì�»ÚGË$S|yù»„ð@9ágnk¨W>X¡%㪠2©åXy®"°ÂÖ!6ü >…ø»" verschlüsselt wurde zu entschlüsseln, als einen der als Key nur "password" verwendet hat?

                  EDIT: Ah... ich glaube ich verstehe. Die Sicherheit erhöht sich dadurch *nicht*, richtig? Weil ja der User rein theoretisch auch alle Sonderzeichen etc verwenden kann?!

                  EDIT2: AES-256 erfordert einen 32-Zeichen schlüssel, richtig? Um diesen zu generieren bietet sich doch aber diese hash-geschichte an!? Ich kann ja von niemandem verlangen, sich 32 Zeichen zu merken.

                  Zitat von David Beitrag anzeigen
                  Salt muss erkennbar und im Klartext mit gespeichert werden, sonst kannst Du keinen vergleichbaren Hash aus der Klartexteingabe erstellen. Es dient nur gegen Rainbow-Tables und der Verschleierung gleicher Passwörter verschiedener Benutzer.
                  Ah. Verstehe endlich...

                  Kommentar


                  • #24
                    • Wenn bekannt ist, dass Du das Passwort erst durch einen Hashalgorithmus schickst, nutzt Dir das nichts. Der `Angreifer´ kann das ja auch.
                    • PHP: mcrypt_generic_init - Manual
                      The maximum length of the key should be the one obtained by calling mcrypt_enc_get_key_size() and every value smaller than this is legal.

                    Kommentar

                    Lädt...
                    X