Das ist wirklich sehr interessant und es funktioniert bei mir einwandfrei. Ich würde dieses System gerne in meinen passwordmanager als Masterkey integrieren, nur verstehe ich nicht so ganz, wie das funktionieren soll, wenn der Hash sich immer verändert. Bitte um Rückmeldung :D
Wird durch den vorherigen SHA nicht die Security-Stärke des Ergebnis Hashes reduziert? Es wird ja einfach die Stellenzahl das PWD reduziert? Bei wiederkehrenden Muster n die über die maximale Länge gehen dürfte das die Wahrscheinlichkeit, dass 2 PWD's den selben Hash haben erhöhen, in Summe aber die Verschlüsselungs-Stärke der Methode reduzieren. Rein so mit Wahrscheinlichkeiten überschlagen. Habe es nicht gerechnet. ;) Grübel? Grübel?
Ja, die Stellenanzahl könnte reduziert werden, aber dafür ist der Wert komplett unvorhersehbar, sprich die Entropie, der echte Zufall, ist deutlich höher. Es gibt auch für Sha noch keine Möglichkeit herauszufinden, welcher Wert durch das hashen entsteht, außer brute force, daher in der Theorie ja, aber nur für perfekte Passwörter - welche tatsächlich ohnehin nicht geknackt werden könnten
Rein theoretisch könnte es dann aber durch das Pre-Hashing sein, dass es einen Pre-Hash A gibt dessen 72 erste Zeichen denen von einem x beliebigen anderen Pre-Hash B entsprechen, es also quasi eine, wie schon bemerkt rein theoretische, erhöhte Kollisions"gefahr" gibt. Oder übersehe ich da etwas?
Aber der Pre-Hash hat doch den Sinn, dass der zu Bearbeitende String maximal 72 Zeichen ist. Zudem muss man fürs Pre-Hashen natürlich einen Algorithmus nehmen, der zurzeit Kollisionsresistent ist. Da sollte also bei richtiger Wahl des Pre-Hash-Algorithmus keine erhöhte Gefahr bestehen.
Bcrypt ist extrem veraltet. Für das hashen von Passwörtern ist einzig und allein Argon2 zulässig, alles andere ist nicht „State of the art“ und widerspricht allen Vorgaben der Cybersecurity.
Super Video. Hast du ein Video wo das mit dem Salt noch Mal ein bisschen besser erklärt wird? Ich hab nicht verstanden, wie der das Passwort ohne Salt wieder "Zurück hashen" kann.
Wenn "Passwort" als Passwort benutzt, ist man sicher nicht der einzige auf der Welt. Wenn man alle häufigen Passwörter sammelt, kann man sie hashen und in eine Rainbow-Tabelle packen. Wenn dann der Hacker den hash von "Passwort" erbeutet hat, braucht er nur in so einer Tabelle nachzuschauen und findet ihn und das dazugehörige Klartextpasswort. Den Salt(z.B. "mysalt") hängt man beim sicheren speichern an "Passwort" hinten an, nimmt also für "Passwortmysalt" den hash, der sich in keiner normalen Rainbow-Tabelle finden wird, wenn der Salt zufällig gewählt wird
Verstehe ich das richtig, das bcrypt im Prinzip nur die Rechenzeit anhebt um ein BruteForce zu erschweren? Weil rein technisch wäre noch ein Salt+PW in SHAxx sonst auch sicher?
"Sicher" ist nicht binär. In der Praxis geht es immer darum, den Aufwand so astronomisch hoch zu machen, dass der Angreifer es sein lässt. Von daher ist "nur die Rechenzeit" das falsche Argument, weil es hier die Metrik für das Sicherheitsniveau ist. In Zeiten von Cloud sollte man aber nicht mehr in Rechenzeit sondern in (Strom-)Kosten rechnen.
Teste einfach mit dem Klartext Passwort die Kriterien. Also Länge, ist ein groß, ein klein, ein Sonderzeichen, eine Zahl enthalten? Wenn nein, aktzeptiere das nicht.
Aber wieso muss ich mir gedanken machen über mein Passwort wenn die Firma / Website wo ich das speichere in einen Hash umwandelt kann ja nichts dran ändern (schonmal vorab ich bin Neueinsteiger in der IT)?
also für den User gilt immer noch: Wenn das Passwort zu leicht ist, kann man's brute forcen. Das Tutorial hier ist allerdings eher für Webseiten-Betreiber gedacht^^
Warum SHA-2-256 ? Wenn bcrypt nur 72 Zeichen (bytes) kann, dann kann man doch auch SHA-2-512 nehmen ? Wäre eine Kombi aus SHA-2 und SHA-3 vorher nicht noch Sicherer ?
Kann man auch machen, SHA256 wurde aber noch nicht gebrochen, also ist es auch nutzbar. Der Sicherheitsaspekt hier ist aber der Bcrypt-Algorithmus, nicht der SHA-2 bzw wie du dir überlegt hast SHA-3 oder eine Kombi. Zudem soll SHA-3 nur eine alternative zu SHA-2 sein, kein Ersatz. Man kanns natürlich implementieren wie man möchte.
Kannst du natürlich machen, aber Sha2 hat vor allem das Problem, schnell zu sein, welches hier irrelevant ist. Die größere Länge ist aber natürlich not bad
@@TheMorpheusTutorials du hast ja mal ein Video zu XOR gemacht, wenn ich jetzt einen SHA3 und SHA2 Hash XORe, also z.b den SHA2 Hash als Key und den SHA3 Hash als Wert, erhöhe ich damit die Sicherheit oder schaffe ich neue Angriffsmöglichkeiten?
Gibs tools für. Eigentlich aber garnicht, weil python wird interpretiert und nicht kompiliert. Gibt tools die machen das umständlich, funktioniert aber nicht immer und teilweise nur semi-gut.
Könnte man es dem Hacker noch weiter erschweren wenn man das Passwort erst mit Sha verschlüsselt und das dann noch durch Bcrypt laufen lässt? Oder is das dann relativ unsinnig
Aber reicht es dann nicht den sha256 Hash zu brutforcen und anstatt dem 500-Zeichen Passwort? Das wäre dann, wenn das so ist, eine Schwachstelle, da es wesentlich einfacher ist ein 128 Zeichen "Passwort", das nur Kleinbuchstaben und Zahlen hat, zu brutforcen als ein 500-Zeichen Passwort mit allen nur erdenklichen Zeichen. (sha256sum gibt 128 Zeichen aus, obwohl 256-Bit doch 32 Zeichen entsprechen müssten?¿?¿?) Des weiteren kann es so doch auch passieren, dass es für den gleichen Hash mehrere mögliche Passwörter geben kann, wenn der nur 256-bit lang ist, oder?
Theoretisch ist dies richtig, praktisch müsstest du die Routine als Angreifer verändern, weil der Pre-Hash Teil der Funktion ist. Was dich vor ernsthafte Schwierigkeiten stellt.
@@patrick6567 Und wenn man die Routine als Angreifer verändern kann, kann man auch praktisch direkt "return True" ausgeben lassen, ohne das Passwort eingeben zu müssen... I guess I see the problem.
@@dragonheart9617 Wenn man die Schritte aufteilt und auf verschiedene Routinen aufteilt, hast du absolut recht…so wie im Video ist das schon eine sehr gute und sichere Möglichkeit. Das bedeutet die beste Lösung, kann durch schlechte Umsetzung noch weitere Schwachstellen generieren.
Der Bcrypt Algorithmus ist aber sehr langsam, wenn man die richtige "Stufe" wählt. Deswegen dauert allein das Probieren der ganzen Möglichkeiten bei nur 128 Zeichen mit Kleinbuchstaben und Zahlen schon ewig lange, das spielt dann keine Rolle mehr. Aber theoretisch hast du recht.
Mein eigenes hashprogramm als ich mit dem programmieren angefangen hab xD: pw = "test" pw = pw.replace("",'@#@') pw-list = pw.split('@#@') for i in range(1, len(pw-list)-1): pwd = pwd + str(ord(pw)) hash = int(pwd) ** z.B. 7 xD return hash I waz an intelligent little scheißer Lul :3
Security by secrecy funktioniert meistens nicht. Wenn jemand an diese Funktion kommt, kann er deine hash-funktion zurückrechnen, wodurch es keine hashfunktion mehr ist.
Übernimmt das nicht das dbms? Und wer speichert local Passwörter auf dem dem pc? Ist doch überflüssig. Vorallem mit dem selben script mit dem man es dekodieren/entschlüsseln kann? Mh
@@TheMorpheusTutorials MariaDB hat aber doch z.B. eine password funktion die automatisch Verschlüsselt. MSSQL hat auch was mit Symetrischer und ASymetrischer Verschlüsselung. Ist das was er meint? Finde die Python Lösung aber VIEL besser und nicht so kompliziert.
Kleiner Denkfehler. Das Hashen von Kennworten dient dazu, dass nicht mal eine Admin den Klartext für das Kennwort sehen kann (und damit auch kein Hacker, der sowohl Datenbank wie Programm lesen könnte.) Datenbankverschlüsselung bezieht sich nur auf die physische Schicht, die Daten sind für die Anwendung natürlich lesbar, sonst macht es keinen Sinn.
