Hallo JanW2, > Eine Frage habe ich noch, da ich mich noch einmal in das Thema "sichere Passwörter" eingelesen habe. > > Aktuell sind meine Passwörter "gesalzen" und gehasht abgespeichert. Das ist gut, aber noch nicht das Optimum. Heutzutage werden Passwörter eigentlich nicht mehr mit den klassischen Hashing-Funktionen wie MD5, dem alten Crypt oder SHA1 oder so gehasht, sondern man verwendet Algorithmen wie [PBKDF2](https://de.wikipedia.org/wiki/PBKDF2), [Bcrypt](https://de.wikipedia.org/wiki/Bcrypt) oder [Scrypt](https://de.wikipedia.org/wiki/Scrypt). PBKDF2 und Bcrypt sind dabei Platzhirsche, die in der überwiegenden Anzahl der Fälle genutzt werden. Perl bietet da auch [Module](http://search.cpan.org/~arodland/Crypt-PBKDF2-0.101170/lib/Crypt/PBKDF2.pm) [zu](http://search.cpan.org/~jaitken/Digest-Bcrypt-1.0.1/lib/Digest/Bcrypt.pm) an. Du solltest, wenn möglich, darauf umsteigen. Die Verwendung kryptologischer Hash-Funktionen ist nicht mehr zeitgemäß, diese Algorithmen sind unter anderem darauf ausgelegt, möglichst schnell einen Hash zu erzeugen. Heutzutage kann sich aber jeder Depp einen Cluster von 1000 Computern mieten, mit dicken Grafikkarten, und dort die Passwörter mit JohnTheRipper auf der Grafikkarte brute-forcen. Die Zielsetzung beim hashen von Passwörtern muss also sein, möglichst viel Rechenzeit für einen Hash-Vorgang zu verbrauchen, um Brute-force-Angriffe teurer zu machen. > Ich weiß, dass das Salt wichtig ist, aber versuche mir klarzumachen, warum dem so ist. Die Sicherheit eines Passwort-Hashes wird definiert durch die mittlere Zeit, die benötigt wird, um den zu dem Hash gehörigen Klartext zu errechnen oder zu erraten. Wenn ich jetzt eine Rainbow-Table habe (die gibt es fertig zum Download in diversen mal mehr, mal weniger zwielichtigen Portalen), bei der bereits alle möglichen Kombinationen drin sind, die ich mit dem Hashing-Verfahren erreichen kann, dann ist es eine Frage von Milli- oder sogar Microsekunden, ein Passwort zu brechen. Setze ich einen Hash dazu, verändere ich die Ausgangslage: es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen. LG, CK -- <https://wwwtech.de/about>

Hallo JanW2, > Eine Frage habe ich noch, da ich mich noch einmal in das Thema "sichere Passwörter" eingelesen habe. > > Aktuell sind meine Passwörter "gesalzen" und gehasht abgespeichert. Das ist gut, aber noch nicht das Optimum. Heutzutage werden Passwörter eigentlich nicht mehr mit den klassischen Hashing-Funktionen wie MD5, dem alten Crypt oder SHA1 oder so gehasht, sondern man verwendet Algorithmen wie [PBKDF2](https://de.wikipedia.org/wiki/PBKDF2), [Bcrypt](https://de.wikipedia.org/wiki/Bcrypt) oder [Scrypt](https://de.wikipedia.org/wiki/Scrypt). PBKDF2 und Bcrypt sind dabei Platzhirsche, die in der überwiegenden Anzahl der Fälle genutzt werden. Perl bietet da auch [Module](http://search.cpan.org/~arodland/Crypt-PBKDF2-0.101170/lib/Crypt/PBKDF2.pm) [zu](http://search.cpan.org/~jaitken/Digest-Bcrypt-1.0.1/lib/Digest/Bcrypt.pm) an. Du solltest, wenn möglich, darauf umsteigen. Die Verwendung kryptologischer Hash-Funktionen ist nicht mehr zeitgemäß, heutzutage kann sich jeder Depp einen Cluster von 1000 Computern mieten, mit dicken Grafikkarten, und dort die Passwörter mit JohnTheRipper auf der Grafikkarte brute-forcen. > Ich weiß, dass das Salt wichtig ist, aber versuche mir klarzumachen, warum dem so ist. Die Sicherheit eines Passwort-Hashes wird definiert durch die mittlere Zeit, die benötigt wird, um den zu dem Hash gehörigen Klartext zu errechnen oder zu erraten. Wenn ich jetzt eine Rainbow-Table habe (die gibt es fertig zum Download in diversen mal mehr, mal weniger zwielichtigen Portalen), bei der bereits alle möglichen Kombinationen drin sind, die ich mit dem Hashing-Verfahren erreichen kann, dann ist es eine Frage von Milli- oder sogar Microsekunden, ein Passwort zu brechen. Setze ich einen Hash dazu, verändere ich die Ausgangslage: es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen. LG, CK -- <https://wwwtech.de/about>