Ich verstehe net wer Sao hasst... also ernsthaft wtf >¶< (bearbeitet) lol dieser Kommentar war random.... Aber es gibt echt viele Leute die Sao net mögen..find ich schade
2:05 Moment, warum sollte der angreifer die zeit mit dem hash berechnen verbringen? Das salt liegt doch auf dem zielsystem und nicht beim client und der hash wird dort berechnet .. oder war das darauf bezogen, dass man zugriff auf eine db hat und nun die Passwörter aus den hashes holen will?
Da du dich ja mit dem Thema relativ gut auskennst: Eine Frage zur Passworthashing. Welcher Hashingalgo wäre deiner Meinung nach am besten bzw. kann man irgendwo nachsehen, welcher Algorithmus derzeitig am sichersten angesehen wird. Ich würde gerne eine Passworthashfunktion sicherer machen, als diese gerade ist.
MD5 ist bspw. nicht sicher ( siehe BSI: www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Empfehlungen/cyberglossar/Functions/glossar.html?cms_lv2=9817296 ). Sicher ist aktuell SHA-512. Eine Liste ist mir nicht bekannt.
@@Florian.Dalwigk Genau, ich hab mich da auch ein wenig drüber Informiert. Wir verwenden z. B. auch nen Algo, der über Rotationen und Iterationen das ganze berechnet (Ich denke, es hieß PBKDF2 mit 10000 oder 100000 iterationen). Aber wie 100% sicher dieser ist, kann ich jetzt nicht sagen. Ich werde mich weiter über die SHA algos mich mal informieren. Dankeschön :)
@@NoName-1337 Das Thema ist sehr komplex und mathematisch hoch anspruchsvoll. Wenn du einen "neuen" Hash-Algorithmus entworfen hast, schaue ich mir den gerne mal an :)
@@Florian.Dalwigk Ne dieser ist schon existent. Ich bin nicht in der Materie so weit fortgeschritten, um einen sicheren Algo zu schreiben. Ich weiß auch, dass man es am besten auch lassen soll, wenn man wenig Ahnung von der Materie hat :D. Meine Implementation gleicht diesem hier cmatskas.com/-net-password-hashing-using-pbkdf2/. Ich verwende allerdings 10000 oder 100000 statt 1000 Iterationen. Und ich denke, dass ich da n paar mehr Bytes verwende. Ich muss mal noch mal nachsehen, die Implementierung ist bereits über 3 Jahre alt (Kann mich da nicht mehr an alle Einzelheiten erinnern)
Jap, das Video bringt's mal auf den Punkt. Salt alleine bringt mal so gar nix, wenn der Mechanismus des Salzens selbst zu einfach ist. Da muss man sich schon was ausdenken, damit das auch wirklich wirkt. Pfeffern ist auch supi, aber nur so lange, wie der Pfeffer nicht offensichtlich ist. Ich verwende bei dem Teil gerne mal code obfuscation. Der Pepper ist im ganzen System verteilt und wird sehr kryptisch zusammengesetzt. Das ist besonders bei Sprachen wie JavaScript wichtig, da diese nicht kompiliert werden. Wenn dann noch Anwendungsserver und Datenbank auf der selben Maschiene laufen ist ein einfaches "In einer config-datei" auch wieder Schmarrn. Am besten heißt die variable dann noch pepper.
Es gibt auch Hash-Algos die für Passworthashing ausgelegt sind wie PBKDF2. Würzen diese die Passwörter auch automatisch, sodass man bis auf den Hash generieren und speichern gar nichts mehr tun muss oder wo genau liegen die Vorteile bei denen? Sind sie schneller?
Cool! Pfeffer kannte ich bislang garnicht. Nur zum Verständnis: Jedee Nutzer bekommt ein zufällig generierten Salt, der wird am besten in einer anderen Datenbank oder cfg Datei gespeichert (im Klartext)? Und Pfeffer kann hardcoded im Quellcode stehen, oder? Wie sieht es da mit der Datensicherheit aus? Ich kann ja bei kompilierten Dateien den Code teilweise dekompilieren oder auf die entsprechende PHP Datei auf dem Server zugreifen. Das wäre ja nur semi sicher.
Ja, das hast du richtig verstanden :) Das Pepper gilt für alle Benutzer gleichermaßen (ist dafür aber zusätzlich geschützt). Ja, man könnte das durch Dekompilieren herausbekommen (doch auch das ist nicht immer möglich). Es dient vor allem dazu, den Angreifer zu verlangsamen (aufhalten kann man ihn in der Theorie nämlich nicht). Nur ein Pepper zu verwenden, halte ich für problematisch (ein Gericht, das nur mit Pfeffer gewürzt wird, schmeckt schließlich auch nicht ;)). Die Kombination aus Salt und Pepper ist schon recht sicher, zumal man ja erstmal an die Daten kommen muss, in denen das Pepper gespeichert ist.
@@Florian.Dalwigk ich denke mit etwas Aufwand ist es immer möglich Strings die mit anderen Dingen interagieren müssen aus dem Code herauszufinden notfalls bei bekannten Verfahren durch brutforce mit bekannten pw und Salt
Sehr gut erklärt. Werde Dein Video weiterempfehlen, wenn Kollegen sich mit dem Hashen nicht recht auskennen. [klugscheissen on] Die gängigen Hashfunktionen basieren meines Wissens nach aber nicht (wie asymmetrische Kryptosysteme) auf den Mathematikproblemen, sondern auf komplexen Verschiebungen, Vertauschungen und Wechseln auf Bitebene, was sie erheblich schneller und hardwarenäher macht. Allerdings ist asymmetrische Verschlüsselung auch ein guter Hashersatz, wenn die Inputlänge konstant und geeignet ist. So kann man ggf. den Nachschlüssel für Strafverfolgung realisieren, weil der Gegenschlüssel im Tresor bleibt oder gleich beim Gericht hinterlegt ist. [klugscheissen off]
zum Passwort sichern braucht man Salt und Pfeffer. (Haha, sehr witzig. Was willst du jetzt damit sagen?) Dies findet man auch in der IT Sicherung (warte mal, was? Das war kein Witz? o.o)
Verstehe ich es richtig, dass salzen und pfeffern aufgabe der website ist, die ich besuche? Und nicht meine aufgabe. Das meine aufgabe lediglich darin besteht ein langes, gutes passwort zu wählen?
Ich bin jetzt (leider oder glücklicherweise) auch mit der Aufgabe betreut ein log-in verfahren zu implementieren. Pfeffer in den Scource-code zu schreiben bekomm ich hin, aber mit dem salzen bin ich noch etwas verwirrt. Mein naiver Ansatz wäre jetzt, einfach eine zweite Datenbank für die Salze zu machen. Aber wie Speicher ich die sicher ab? Die gehashed zu speichern und dann zu enthashen um sie an das User Password dran zuhängen klingt ja relativ dumm, weil zum hashen ja Einwegsfunktionen benutzt werden. Im Klartext bringts mir ja aber auch nicht viel, weil wenn die erste DB weg ist, die zweite ja eventuell mitbetroffen sein kann. Kann mir jemand gute rescourcen zu dem Thema empfehlen oder einen Ansatz geben?
Aber, was ich nicht ganz verstehe: Wie sollte ich das Salt speichern? Wenn jemand auf die Datenbank Zugriff hat, hat er ja auch das Salt, und somit ist es wieder relativ einfach, oder nicht?
@@Florian.Dalwigk Wo würdest du die Config-Date ablegen und wie würdest du die Config-Datei absichern? Ich würde eine salt.conf in /var/www ablegen und dem user und der group www-data zuweisen mit den Berechtigungen -rw-------.
Überlegung: Hash von Benutzername und Passwort. der Hash des Passwortes wird ausgewertet, um zu entscheiden, ob für den nächsten Schritt der Namens- oder der Passwort-Hash verwendet wird. Der gewählte Hash wird ausgewertet, um nach der selben Auswertung wie oben zwei Werte zu ermitteln: erstes Zeichen und Länge des Salt. Dann wird der Salt entsprechend aus dem jeweils anderen Hashwert bezogen (also ab Stelle 5, 9 Stellen lang, als Beispiel). Dann wird das Klartext-Passwort + Salt (oder anders rum) gehasht und dieser Wert kommt, zusammen mit einer "genormten" Version des Benutzernamens (z.B. alles lowercase), in die DB. Ergebnis: Der Salt muss nicht mehr gespeichert werden sondern wird durch korrekte, case-sensitive Angabe von Benutzername und Passwort ermittelt. Wäre das besser oder schlechter als ein individuell vergebener, zufälliger aber gespeicherter salt?
@@Florian.Dalwigk Nächste Frage: Macht es Sinn, diese Überlegung als js-code umzusetzen? Dass ich gezielt nach js frage hat offensichtlich den Hintergrund, dass damit alles client-seitig stattfindet und im Falle einer versehentlich unverschlüsselten Verbindung wenigstens keine Klartext-Daten übermittelt werden können. Und ich glaube, den Code zu kennen, der den Hash erzeugt, ist an der Stelle weniger bedenklich als die Logindaten unverschlüsselt zu übermitteln.
Leider nicht :( Es gibt sehr viele Seitenbetreiber, denen das egal ist. Wenn ich euch mal einen Dienst mit Login zur Verfügung stelle, könnt ihr aber sicher sein, dass die Passwörter ordentlich gewürzt sind 😉
@@Florian.Dalwigk Aber ich finde grade bei so wichtigen sachen wie Finazdienstleistungen bsw. Paypal sollten gewürzte Passwörter gesetzlich verpflichtent sein.
Da stimme ich dir zu. PayPal Und Co machen das wahrscheinlich auch. Lustigerweise gibt es ja aber momentan die Überlegung, Verschlüsselung mit einer Art Generalschlüssel für ermittelnde Behörden auszuhebeln. Ob das durchgeht 🤷♂️
Ich bräuchte Hilfe mit einem Python-Pogramm: Es soll eine quadratische Tabelle mit 16 Zeilen und 16 Spalten erzeugt werden. Die Werte der Tabellenelemente sind die Zahlen von 0 - 255 (256 dezimale Bytewerte) und müssen aus den Tabellenparametern (Tabellengröße, Zeilenzählwert, Spaltenzählwert) berechnet werden. Sodann die Tabellenstruktur in Tabellenform anzeigen: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] [16,..............., 31] [...............] [240,....., 255]
Moin, 2:00 ich habe mich gefragt, warum bei mir mit "echo Passwort |sha256sum" eine anderer, kürzerer Hashwert raus kommt. Hier die Versuche. Das dritte stimmt überein...: echo Passwort |sha256sum a4722c7e39b6c2138189c39494223b3446ffdde4d82241036a101bc2ab52c86f - sha256sum < Passwort e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - echo -n Passwort |sha512sum aaf6a7d781d14ad069bf26988cbda52043197c14f3a9762778a7ba9d31bebce0bfbb27368e39c18471dc611731877cd4796b80c660ff9be2d0d63eaa649c4c1d - LG juck.
Wie immer geiles und informatives Video 💪🏼
Merci!
Cooles und informatives Video. Das man ordentlich salzen sollte war mir bekannt, gepfeffert hab ich bis jetzt aber noch nicht.
Die Mischung macht's. Jetzt werden deine Passwörter noch besser schmecken ;)
Ich habe auch schon gehört dass leute paprika und Rosmarin verwenden.
Schmeckt bestimmt auch gut.
Gut gewürztes Video!
Haha, danke :) Ich freue mich, dass ich deinen Geschmack getroffen habe!
Sword Art Online
:)
Ich verstehe net wer Sao hasst... also ernsthaft wtf >¶<
(bearbeitet) lol dieser Kommentar war random.... Aber es gibt echt viele Leute die Sao net mögen..find ich schade
Sehr schmackhaft! :)
Die Mischung macht's :D
Danke ich glaube das Video hat mir vllt theoretisch geholfen
Guter Content!
Vielen Dank! Es freut mich, dass dir mein Content gefällt :)
Perfekt :)
Merci :)
2:05 Moment, warum sollte der angreifer die zeit mit dem hash berechnen verbringen? Das salt liegt doch auf dem zielsystem und nicht beim client und der hash wird dort berechnet .. oder war das darauf bezogen, dass man zugriff auf eine db hat und nun die Passwörter aus den hashes holen will?
Man hat DB Zugriff
Da du dich ja mit dem Thema relativ gut auskennst: Eine Frage zur Passworthashing. Welcher Hashingalgo wäre deiner Meinung nach am besten bzw. kann man irgendwo nachsehen, welcher Algorithmus derzeitig am sichersten angesehen wird. Ich würde gerne eine Passworthashfunktion sicherer machen, als diese gerade ist.
MD5 ist bspw. nicht sicher ( siehe BSI: www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Empfehlungen/cyberglossar/Functions/glossar.html?cms_lv2=9817296 ). Sicher ist aktuell SHA-512. Eine Liste ist mir nicht bekannt.
@@Florian.Dalwigk Genau, ich hab mich da auch ein wenig drüber Informiert. Wir verwenden z. B. auch nen Algo, der über Rotationen und Iterationen das ganze berechnet (Ich denke, es hieß PBKDF2 mit 10000 oder 100000 iterationen). Aber wie 100% sicher dieser ist, kann ich jetzt nicht sagen. Ich werde mich weiter über die SHA algos mich mal informieren. Dankeschön :)
@@NoName-1337 Das Thema ist sehr komplex und mathematisch hoch anspruchsvoll. Wenn du einen "neuen" Hash-Algorithmus entworfen hast, schaue ich mir den gerne mal an :)
@@Florian.Dalwigk Ne dieser ist schon existent. Ich bin nicht in der Materie so weit fortgeschritten, um einen sicheren Algo zu schreiben. Ich weiß auch, dass man es am besten auch lassen soll, wenn man wenig Ahnung von der Materie hat :D.
Meine Implementation gleicht diesem hier cmatskas.com/-net-password-hashing-using-pbkdf2/. Ich verwende allerdings 10000 oder 100000 statt 1000 Iterationen. Und ich denke, dass ich da n paar mehr Bytes verwende. Ich muss mal noch mal nachsehen, die Implementierung ist bereits über 3 Jahre alt (Kann mich da nicht mehr an alle Einzelheiten erinnern)
Hallo, gut erklärt. Gibt es dazu auch ein Video wie man dass z.b. mit VBA in MS Access macht. Danke und Gruss aus der Schweiz.
Ich habe dazu noch kein Video erstellt. Viele Grüße in die Schweiz.
In Python hab ich das mal gemacht.
@@Florian.Dalwigk Danke, da frage ich mich doch: Planst Du mal eins zu machen. würde sicher vielen helfen
Ich überlege es mir
Jap, das Video bringt's mal auf den Punkt. Salt alleine bringt mal so gar nix, wenn der Mechanismus des Salzens selbst zu einfach ist. Da muss man sich schon was ausdenken, damit das auch wirklich wirkt. Pfeffern ist auch supi, aber nur so lange, wie der Pfeffer nicht offensichtlich ist. Ich verwende bei dem Teil gerne mal code obfuscation. Der Pepper ist im ganzen System verteilt und wird sehr kryptisch zusammengesetzt. Das ist besonders bei Sprachen wie JavaScript wichtig, da diese nicht kompiliert werden. Wenn dann noch Anwendungsserver und Datenbank auf der selben Maschiene laufen ist ein einfaches "In einer config-datei" auch wieder Schmarrn. Am besten heißt die variable dann noch pepper.
Danke sehr Informativ, auch wenn ich alles schon wusste. Wo bleibt der Discord-Server?
Langsam reicht es mit den Nachfragen nach dem Discord!
Food Wars! Shokugeki no Soma hätte besser als Anime dazu gepasst :3 (Aber ehre das du SAO genommen hast!)
Haha, Food Wars wäre perfekt gewesen ;)
Es gibt auch Hash-Algos die für Passworthashing ausgelegt sind wie PBKDF2. Würzen diese die Passwörter auch automatisch, sodass man bis auf den Hash generieren und speichern gar nichts mehr tun muss oder wo genau liegen die Vorteile bei denen? Sind sie schneller?
Standardisierter
Cool! Pfeffer kannte ich bislang garnicht. Nur zum Verständnis: Jedee Nutzer bekommt ein zufällig generierten Salt, der wird am besten in einer anderen Datenbank oder cfg Datei gespeichert (im Klartext)? Und Pfeffer kann hardcoded im Quellcode stehen, oder? Wie sieht es da mit der Datensicherheit aus? Ich kann ja bei kompilierten Dateien den Code teilweise dekompilieren oder auf die entsprechende PHP Datei auf dem Server zugreifen. Das wäre ja nur semi sicher.
Ja, das hast du richtig verstanden :) Das Pepper gilt für alle Benutzer gleichermaßen (ist dafür aber zusätzlich geschützt). Ja, man könnte das durch Dekompilieren herausbekommen (doch auch das ist nicht immer möglich). Es dient vor allem dazu, den Angreifer zu verlangsamen (aufhalten kann man ihn in der Theorie nämlich nicht). Nur ein Pepper zu verwenden, halte ich für problematisch (ein Gericht, das nur mit Pfeffer gewürzt wird, schmeckt schließlich auch nicht ;)). Die Kombination aus Salt und Pepper ist schon recht sicher, zumal man ja erstmal an die Daten kommen muss, in denen das Pepper gespeichert ist.
@@Florian.Dalwigk ich denke mit etwas Aufwand ist es immer möglich Strings die mit anderen Dingen interagieren müssen aus dem Code herauszufinden notfalls bei bekannten Verfahren durch brutforce mit bekannten pw und Salt
0:44 haha die Namen :D
Erkannt? :)
Sehr gut erklärt. Werde Dein Video weiterempfehlen, wenn Kollegen sich mit dem Hashen nicht recht auskennen. [klugscheissen on] Die gängigen Hashfunktionen basieren meines Wissens nach aber nicht (wie asymmetrische Kryptosysteme) auf den Mathematikproblemen, sondern auf komplexen Verschiebungen, Vertauschungen und Wechseln auf Bitebene, was sie erheblich schneller und hardwarenäher macht. Allerdings ist asymmetrische Verschlüsselung auch ein guter Hashersatz, wenn die Inputlänge konstant und geeignet ist. So kann man ggf. den Nachschlüssel für Strafverfolgung realisieren, weil der Gegenschlüssel im Tresor bleibt oder gleich beim Gericht hinterlegt ist. [klugscheissen off]
Danke für dein Feedback :) Ich gebe dir Recht: Viele Hashfunktionen basieren nicht auf konkreten Mathematik*problemen*.
Salt 'n' Pepper, bekomm ich sofort nen Ohrwurm.
Ist das ein Lied?
@@Florian.Dalwigk Salt 'n Peppa ist eine Mädels Hip-Hop Band, die vor allem in den 90ern sehr aktiv waren.
zum Passwort sichern braucht man Salt und Pfeffer. (Haha, sehr witzig. Was willst du jetzt damit sagen?) Dies findet man auch in der IT Sicherung (warte mal, was? Das war kein Witz? o.o)
Nein, das war kein Witz ;)
Verstehe ich es richtig, dass salzen und pfeffern aufgabe der website ist, die ich besuche? Und nicht meine aufgabe. Das meine aufgabe lediglich darin besteht ein langes, gutes passwort zu wählen?
Ja
Ich bin jetzt (leider oder glücklicherweise) auch mit der Aufgabe betreut ein log-in verfahren zu implementieren. Pfeffer in den Scource-code zu schreiben bekomm ich hin, aber mit dem salzen bin ich noch etwas verwirrt. Mein naiver Ansatz wäre jetzt, einfach eine zweite Datenbank für die Salze zu machen. Aber wie Speicher ich die sicher ab? Die gehashed zu speichern und dann zu enthashen um sie an das User Password dran zuhängen klingt ja relativ dumm, weil zum hashen ja Einwegsfunktionen benutzt werden. Im Klartext bringts mir ja aber auch nicht viel, weil wenn die erste DB weg ist, die zweite ja eventuell mitbetroffen sein kann. Kann mir jemand gute rescourcen zu dem Thema empfehlen oder einen Ansatz geben?
Jetzt hab ich Hunger
🍔
Nice
👍
Aber, was ich nicht ganz verstehe: Wie sollte ich das Salt speichern? Wenn jemand auf die Datenbank Zugriff hat, hat er ja auch das Salt, und somit ist es wieder relativ einfach, oder nicht?
In einer anderen Datenbank oder einer speziell geschützten und geloggten Konfigurationsdatei.
@@Florian.Dalwigk Wo würdest du die Config-Date ablegen und wie würdest du die Config-Datei absichern?
Ich würde eine salt.conf in /var/www ablegen und dem user und der group www-data zuweisen mit den Berechtigungen -rw-------.
😂eugeo=senpai
Hat das keio.ac in den Domainnamen eine tiefere Bedeutung?
;)
www.keio.ac.jp/ ist die Webseite der Keio Universität in Japan :D
Danke, man lernt nie aus 😁
;)
Ist am sichersten
(Starkes Passwort+ salz&Pfeffer + 2-Faktor dings), oder geht es noch besser?🙃
Sicherer geht immer ;) Doch das sollte schon sehr sicher sein!
Großer Sao fan... so einer also ¬0¬
... Ich auch xD
Haha, ja 😊
Ich hätte ne Frage...
Gibt's eigentlich nen dc Server?
Überlegung: Hash von Benutzername und Passwort. der Hash des Passwortes wird ausgewertet, um zu entscheiden, ob für den nächsten Schritt der Namens- oder der Passwort-Hash verwendet wird. Der gewählte Hash wird ausgewertet, um nach der selben Auswertung wie oben zwei Werte zu ermitteln: erstes Zeichen und Länge des Salt. Dann wird der Salt entsprechend aus dem jeweils anderen Hashwert bezogen (also ab Stelle 5, 9 Stellen lang, als Beispiel). Dann wird das Klartext-Passwort + Salt (oder anders rum) gehasht und dieser Wert kommt, zusammen mit einer "genormten" Version des Benutzernamens (z.B. alles lowercase), in die DB.
Ergebnis: Der Salt muss nicht mehr gespeichert werden sondern wird durch korrekte, case-sensitive Angabe von Benutzername und Passwort ermittelt.
Wäre das besser oder schlechter als ein individuell vergebener, zufälliger aber gespeicherter salt?
Das ist ein richtig guter Ansatz!
@@Florian.Dalwigk Nächste Frage: Macht es Sinn, diese Überlegung als js-code umzusetzen? Dass ich gezielt nach js frage hat offensichtlich den Hintergrund, dass damit alles client-seitig stattfindet und im Falle einer versehentlich unverschlüsselten Verbindung wenigstens keine Klartext-Daten übermittelt werden können. Und ich glaube, den Code zu kennen, der den Hash erzeugt, ist an der Stelle weniger bedenklich als die Logindaten unverschlüsselt zu übermitteln.
Ergibt Sinn!
Und man kann sich darauf verlassen das Webseiten die beiden Gewürze auch wirklich anwenden?
Leider nicht :( Es gibt sehr viele Seitenbetreiber, denen das egal ist. Wenn ich euch mal einen Dienst mit Login zur Verfügung stelle, könnt ihr aber sicher sein, dass die Passwörter ordentlich gewürzt sind 😉
@@Florian.Dalwigk Aber ich finde grade bei so wichtigen sachen wie Finazdienstleistungen bsw. Paypal sollten gewürzte Passwörter gesetzlich verpflichtent sein.
Da stimme ich dir zu. PayPal Und Co machen das wahrscheinlich auch. Lustigerweise gibt es ja aber momentan die Überlegung, Verschlüsselung mit einer Art Generalschlüssel für ermittelnde Behörden auszuhebeln. Ob das durchgeht 🤷♂️
@@Florian.Dalwigk Gibt es denn ne Möglichkeit fest zu stellen ob online Dienstanbieter ihre Passwörter würzen. Auf was muss man da achten?
Keine Chance. Außrr du kommst an einen Passwort-Hash 🙂
Ich bräuchte Hilfe mit einem Python-Pogramm:
Es soll eine quadratische Tabelle mit 16 Zeilen und 16 Spalten erzeugt werden.
Die Werte der Tabellenelemente sind die Zahlen von 0 - 255 (256 dezimale Bytewerte) und müssen aus den Tabellenparametern (Tabellengröße, Zeilenzählwert, Spaltenzählwert) berechnet werden.
Sodann die Tabellenstruktur in Tabellenform anzeigen:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
[16,..............., 31]
[...............]
[240,....., 255]
Ich habe auch schon geantwortet: informatikstudium.net/index.php/438/zeichencode-tabelle-mit-python-tabelle
Wo studierst du?
Ich habe an der Hochschule München Informatik studiert. Mittlerweile studiere ich an der Fernuniversität in Hagen meinen Master in Informatik.
Asuna und kirito aus sao????
Jepp
irre gut erklärt
Danke 😁
Haha auch ein SAO Fan?
Und wie :) Ich habe auch noch andere Videos auf dem Kanal, in denen ich SAO referenzier ;)
Z. B. hier: ruclips.net/video/R3LKp8IQmJ8/видео.html :D
epic weeb
🙄
@@Florian.Dalwigk danke man, hast mir geholfen :b
Sehr schön :)
Moin,
2:00 ich habe mich gefragt, warum bei mir mit "echo Passwort |sha256sum" eine anderer, kürzerer Hashwert raus kommt.
Hier die Versuche. Das dritte stimmt überein...:
echo Passwort |sha256sum
a4722c7e39b6c2138189c39494223b3446ffdde4d82241036a101bc2ab52c86f -
sha256sum < Passwort
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -
echo -n Passwort |sha512sum
aaf6a7d781d14ad069bf26988cbda52043197c14f3a9762778a7ba9d31bebce0bfbb27368e39c18471dc611731877cd4796b80c660ff9be2d0d63eaa649c4c1d -
LG
juck.
Das ist ein Beispiel
LG
Florian.