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.
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^^
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.
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?
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.
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
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.
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.
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
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.
![Sending files over the network with Python [Sockets].](/img/n.gif)
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?
Würde mich auch interessieren
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
Das Video kommt wie gerufen. Hab mir die letzte Woche den Kopf drüber zerbrochen, wie ich gescheit salze.
Sehr gutes Video, wie immer
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.
man kann das gehashde passwort einfach nochmal hashen? 7:20
und auch ganz wichtig : soweit möglich niee authentication selber implementieren
Danke für das Tutorial
Wie kommst du darauf dass nach dem ersten Mal abc mit MD5 das Gleiche herauskommt wenn du den MD5 String noch mal hascht? 05:30
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^^
@@TheMorpheusTutorials Ok danke und ich danke dir auch für alle Videos, die du online stellst, sind nämlich sehr informativ und interessant :)
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.
Du klingst echt wie Stefan Raab 😀
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?
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.
Dazu kommt noch, dass es ja keine Patterns gibt, jeder hash wäre gültig und damit hast du Rechenzeiten von Millionen Jahren
Welches Programm nutzt du zum Python schreiben?
PyCharm
@@vawvaw7084 Danke
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
Erschweren nicht wirklich, dann eher die Runden hoch stellen 😊
@@TheMorpheusTutorials schade, hatte gehofft, dann wir das es dezent schwerer für den Hacker :(
Super hilfreich!
Kannst du mal Zeigen wie man einen Algorithmus in Python schreibt der den User "zwingt" ein sicheres Password zunehmen?
Liebe Grüße
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.
Sehr interessant
Ich baue gerade ne blog app, wo ich die technik benutze
Kannst du mal ein Tutorial dazu machen, wie man .py zu .exe konvertiert?
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.
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.
Werde das zwar nicht coden & kenne mich ned mit python aus aber ich liebe es dir zuzuschauen
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
@@LB-qr7nv aber der Salt wird doch jedes Mal neu generiert. Wir kann man das dann vergleichen?
@@N1CK145 das hat mich auch gewundert. Vielleicht habe ich was falsch verstanden, aber eigentlich sollte er im Klartext gespeichert werden müssen
@@LB-qr7nv so wie du es erklärt hattest, kannte ich das auch ^^
Hi ich habe ein Problem beim bot coden in Vs Studio codes mit js kanst du mir bitte helfen
@Mr.G ja
@Mr.G ok ich habe danach gesucht aber nichst gefunden
@Mr.G wenn ich versuche den bot zu starten kommt ein Fehler raus und den finde ich nicht im internet
@Mr.G das weiß ich nicht
Hast du dc das ich dir das Bild schicken kann ?
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.
@@1996Pinocchio mittlerweile weiß ich das ja xD
Kannst du auch Videos zum Scripting mit PowerShell machen?
Ü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
Das ist für das DBMS bzw das Backend 😅 eine Datenbank verschlüsselt normalerweise nicht
@@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.