Erzeugt man sich einen MD5-Hash…

---

<einschub>
Es ist keine gute Idee einen MD5-Hash auf irgendwelchen Websites online erzeugen zu lassen, da man nicht sicher sein kann, dass nicht das Passwort sofort inkl. dem Hash in einer Datenbank von MD5-Crackern landet.

md5encrypter.com erzeugt einen MD5-Hash, schreibt diesen aber auch gleich in die eigene Datenbank, womit das vermeintliche Passwort verbrannt ist.

Wenn man diesen Hash aba1f53a93fa2b755f04b66e230aa636 hier md5decrypter.com suchen lässt, so sieht man das Problem. :O)

Und da auch andere MD5-Cracker auf deren Datenbank zugreifen, ist die weitere Verbreitung gesichert… z.B.: md5.igrkio.info/md5-hash-database.html

Man kann auch den MD5-Hash per JavaScript erzeugen, um es auf dem eigenen Rechner auszuführen: aktuell.de.selfhtml.org/artikel/javascript/md5/
Leider gibt es mit JavaScript und MD5 ein Problem, sobald man z.B. Umlaute hashen will, wird ein falscher Hash erzeugt.

In PHP wäre es einfach nur: <? echo md5('sicheres_password') ?>
</einschub>

---

Sobald man von seinem Passwort den MD5-Hash erzeugt hat und per Google danach sucht, so sollte nichts gefunden werden. Auch bei den MD5-Crackern wie z.B. md5cracker.org, sollte es keine Funde dazu geben. Wenn doch irgendwo der Hash, bzw. das Passwort dazu, gefunden werden sollte, so ist das Passwort unsicher.


Was macht nun der kriminelle Hacker mit dem Wissen um MD5, der Erkenntnis das User (UND User mit Adminstatus!) meist unsichere Passworte benutzen, die meisten Systeme ungesalzene (Salt (Kryptologie) de.wikipedia.org) Hashes in der Datenbank speichern, Softwareentwickler und Webmaster oftmals grundlegende Sicherheitsregeln missachten?

Als ersten Schritt erzeugt sich der Angreifer einen Hash von einem weit verbreitetem Passwort. Mit diesem Hash füttert er Google und hofft, das möglichst die “richtigen” Websites in den Suchergebnissen auftauchen. Erweitert er den Suchstring noch durch ext:sql, so wird ihm Google alle Seiten zeigen, die Dateien mit der Dateiendung sql, im für Suchmaschinen zugänglich Bereich, gespeichert haben.

Dateien mit der Endung sql sind meist Installationsdateien, die bei der ersten Installation von Content Management Systemen, Shops, etc. verwendet werden. Diese enthalten meist die Standardeinstellung (User/Passwort) für den ersten Benutzer im System. Nach der Installation wird man dann auch immer darauf hingewiesen, diese Zugangsdaten dringend zu ändern. Backups von den Datenbankinhalten werden aber auch meist als eine Datei mit der Endung sql gespeichert. Diese sql-Dateien sind Textdateien, die nicht codiert sind, deren Inhalt ist also im Klartext lesbar.

Der Angreifer kann nun hoffen Backups (oder SQL-Exporte die nach einem Serverumzug importiert werden mussten) zu finden, die der Admin nicht gelöscht hat. Da die Backups von Datenbanken auch die Zugangsdaten zu dem CMS enthalten, kann sich der Angreifer evtl. mit Hilfe der MD5-Cracker erfolgreich ein funktionierendes Passwort beschaffen und sich unbemerkt in das System einloggen.

Sollte der Angreifer erfolgreich in ein System eingedrungen sein, so kann er allen Besuchern der Website “seine” Inhalte anbieten und kein Besucher wird ahnen, dass diese von einem kriminellen Hacker kommen.


Wenn ein Angreifer wirklich so weit gekommen ist, dass er die Besucher der Website mit seinen Inhalten füttern kann, so sind schon mehrere Sicherheitsregeln missachtet worden:

• DirectoryListing ist aktiviert.
  Es werden die Dateien in den Verzeichnissen der Website im Browser angezeigt. Ist das Listing aktiviert, so wird Google alle Dateien, und wenn möglich auch deren Inhalte, im Index aufnehmen.
  Verantwortlich: Admin/Seitenbetreiber
• Backup- oder Exportdateien von der Datenbank sind nicht gelöscht worden.
  Verantwortlich: Admin/Seitenbetreiber
• Der MD5-Hash für ein Passwort wird ungesalzen in der Datenbank gespeichert.
  Verantwortlich: Entwickler der Software (CMS, Shop, Blog, etc.)
• Das Passwort für den MD5-Hash kann mit einem MD5-Cracker ermittelt werden.
  Verantwortlich: User, der unsicherer Passworte vergibt

Da viele User ihr Passwort(e?) meist über viele Jahre nicht ändern und ein und dasselbe Passwort für verschiedene Seiten/Dienste benutzen, besteht auch immer die Gefahr, dass der Angreifer auf andere Accounts des Users (eBay, Paypal, Webmail, etc.) zugreifen kann. Ein User hat i.d.R. keinen Einfluss und keine Einsicht darüber, was Softwareentwickler und Websitebetreiber tun oder lassen, daher kann man ihm nur raten:

• Sichere Passworte zu wählen,
• diese regelmäßig (Der Hallescher Komet besucht die Erde auch regelmäßig!?) mehrmals im Jahr, zu ändern und
• kein Passwort-Recycling zu betreiben. Ein Passwort – eine Website!