Admidio-Version: 2.2.5
Hallo zusammen,
mir ist aufgefallen, dass anscheinend folgendes Passwort zwar in Admidio eingegeben/gesetzt werden kann, allerdings beim Login anschließend der Zugriff verweigert wird.
Passwort: bf4f51403aa5f6d73040ec7414dd7b66
Da das Passwort aus 32 Zeichen (128Bit) besteht, genau wie der in Admidio 2.2.5 genutzte MD5-Hash, habe ich auch das selbe Passwort nur ohne das letzte Zeichen ausprobiert. Aber mit folgendem Passwort tritt das selbe Problem auf wie oben.
Passwort: bf4f51403aa5f6d73040ec7414dd7b6
Vermutung:
Da der MD5-Hash scheinbar richtig in die Datenbank eingetragen wird, wird die Passwortlänge möglicherweise beim Login abgeschnitten bzw. auf eine bestimmte Maximallänge begrenzt.
Ich konnte das noch nicht überprüfen, da ich neu im Umgang mit Admidio bin und noch nicht die nötige Zeit aufbringen konnte mir das genauer anzuschauen.
Sollte aber meine Vermutung zutreffen, so müsste diese Maximallänge bei Passworteingaben (sowohl Login als auch Setzten des Passworts) überprüft und ggf. dem Nutzer gemeldet werden.
Grüße,
Michael
P.S.: Natürlich ist die Dringlichkeit des Problems eher gering einzuschätzen, da wohl kaum Nutzer wirklich die 128Bit des MD5-Hashs in ihrer Passwortlänge ausnutzen.
Passwort zu lang?
-
matzman2000
- Former team member
- Beiträge: 1087
- Registriert: 2. Sep 2007, 17:12
- Wohnort: Itzstedt
- Kontaktdaten:
langes Passwort -> kein MD5-Hash?
Hallo nochmal!
Erstmal danke an matzman2000 für die schnelle Antwort.
Ich hab mir das nochmal angeschaut. Ich kann das Problem wie ich es ursprünglich hatte nun auch nicht mehr rekonstruieren. Allerdings habe ich in der Zwischenzeit auch auf die Admidio Version 2.2.6 geupdatet.
Mir ist aber jetzt der mögliche Grund für mein Problem aufgefallen:
Ich hatte das Problem ursprünglich nachdem ich das Passwort bf4f51403aa5f6d73040ec7414dd7b66 direkt bei der Installation gesetzt hatte. Anschließend konnte ich mich nicht damit einloggen.
Also habe ich versucht das Passwort in der Datenbank-Tabelle "adm_users" zu überschreiben. Dort wollte ich den zu meinem Passwort (bf4f51403aa5f6d73040ec7414dd7b66) entsprechenden MD5-Hash (842d082e8260e1f9c7cc7a75968d2884) eintragen.
Aber damit konnte ich mich auch nicht einloggen.
Also habe ich ein kürzeres Passwort ("testtest") probiert und den entsprechenden Hash (05a671c66aefea124cc08b76ea6d30bb) in die Datenbank-Tabelle eingetragen. Damit konnte ich mich dann einloggen.
Jetzt habe ich folgendes festgestellt:
Benutze ich das Passwort bf4f51403aa5f6d73040ec7414dd7b66, so speichert Admidio nicht den zu erwartenden MD5-Hash in der Datenbank-Tabelle "adm_users" ab. Statt dem von mir erzeugten (und damit erwarteten) MD5-Hash 842d082e8260e1f9c7cc7a75968d2884 steht in der Datenbank der Hash d6938ef74c8dd2f11195b967e2f16a90. Bei dem um ein Zeichen kürzeres Passwort bf4f51403aa5f6d73040ec7414dd7b6 entsteht der selbe Effekt.
Ich habe noch nicht überprüft, ob vielleicht absichtlich nicht der zu erwartende MD5-Hash in der Datenbank steht (z.B. aufgrund von Kompression etc.).
In jedem Fall scheint daraus im Moment zumindest kein direktes Problem zu entstehen.
Erstmal danke an matzman2000 für die schnelle Antwort.
Ich hab mir das nochmal angeschaut. Ich kann das Problem wie ich es ursprünglich hatte nun auch nicht mehr rekonstruieren. Allerdings habe ich in der Zwischenzeit auch auf die Admidio Version 2.2.6 geupdatet.
Mir ist aber jetzt der mögliche Grund für mein Problem aufgefallen:
Ich hatte das Problem ursprünglich nachdem ich das Passwort bf4f51403aa5f6d73040ec7414dd7b66 direkt bei der Installation gesetzt hatte. Anschließend konnte ich mich nicht damit einloggen.
Also habe ich versucht das Passwort in der Datenbank-Tabelle "adm_users" zu überschreiben. Dort wollte ich den zu meinem Passwort (bf4f51403aa5f6d73040ec7414dd7b66) entsprechenden MD5-Hash (842d082e8260e1f9c7cc7a75968d2884) eintragen.
Aber damit konnte ich mich auch nicht einloggen.
Also habe ich ein kürzeres Passwort ("testtest") probiert und den entsprechenden Hash (05a671c66aefea124cc08b76ea6d30bb) in die Datenbank-Tabelle eingetragen. Damit konnte ich mich dann einloggen.
Jetzt habe ich folgendes festgestellt:
Benutze ich das Passwort bf4f51403aa5f6d73040ec7414dd7b66, so speichert Admidio nicht den zu erwartenden MD5-Hash in der Datenbank-Tabelle "adm_users" ab. Statt dem von mir erzeugten (und damit erwarteten) MD5-Hash 842d082e8260e1f9c7cc7a75968d2884 steht in der Datenbank der Hash d6938ef74c8dd2f11195b967e2f16a90. Bei dem um ein Zeichen kürzeres Passwort bf4f51403aa5f6d73040ec7414dd7b6 entsteht der selbe Effekt.
Ich habe noch nicht überprüft, ob vielleicht absichtlich nicht der zu erwartende MD5-Hash in der Datenbank steht (z.B. aufgrund von Kompression etc.).
In jedem Fall scheint daraus im Moment zumindest kein direktes Problem zu entstehen.
Hi,
mit knacken hat das bei leichten Passwörtern meist wenig zu tun. Es gibt einfach Datenbanken in denen die Hashs zu ganzen Wörterbüchern hinterlegt werden. Was dann eine Rückwärtssuche erlaubt. Wenn ich den Hashwert von einem Passwort habe und einfach nachsehen kann, welches Wort da verschlüsselt wurde hilft auch die beste Verschlüsselung nichts, nur ein gutes Passwort.
Gruß Jochen
mit knacken hat das bei leichten Passwörtern meist wenig zu tun. Es gibt einfach Datenbanken in denen die Hashs zu ganzen Wörterbüchern hinterlegt werden. Was dann eine Rückwärtssuche erlaubt. Wenn ich den Hashwert von einem Passwort habe und einfach nachsehen kann, welches Wort da verschlüsselt wurde hilft auch die beste Verschlüsselung nichts, nur ein gutes Passwort.
Gruß Jochen
Hallo,
da muss ich dir leider widersprechen Jochen und lolhonk recht geben:
Das Admidio (zumindest bei normal langen Passwörten) keine Salted Hashes verwendet, ist eindeutig ein Sicherheitsrisiko in Admidio.
Denn deine angesprochenen Datenbanke mit Hashes und Passwörtern (Rainbowtables) funktionieren bei Salted Hashes nicht.
Du hast aber natürlich recht, dass sehr komplexe Passwörter in diesen Rainbowtables meist nicht vorkommen (und man dann auch "sicherer" ist), aber man kann sich einfach nicht darauf verlassen, dass die Nutzer wirklich lange und komplexe Passwörter verwenden. Ganz im Gegenteil, die meisten Anwender verwenden Passwörter wie "passwort" oder "123456".
Aber natürlich müssen die gesalzenen Passwort-Hashes erst implementiert werden, was bei einem Open Source Projekt immer etwas Zeit in Anspruch nimmt.
Zusätzlich muss ein Angreifer ja auch erst mal an die Hash-Werte kommen, die im Normalfall nicht so leicht ausgelesen werden können.
Grüße!
da muss ich dir leider widersprechen Jochen und lolhonk recht geben:
Das Admidio (zumindest bei normal langen Passwörten) keine Salted Hashes verwendet, ist eindeutig ein Sicherheitsrisiko in Admidio.
Denn deine angesprochenen Datenbanke mit Hashes und Passwörtern (Rainbowtables) funktionieren bei Salted Hashes nicht.
Du hast aber natürlich recht, dass sehr komplexe Passwörter in diesen Rainbowtables meist nicht vorkommen (und man dann auch "sicherer" ist), aber man kann sich einfach nicht darauf verlassen, dass die Nutzer wirklich lange und komplexe Passwörter verwenden. Ganz im Gegenteil, die meisten Anwender verwenden Passwörter wie "passwort" oder "123456".
Aber natürlich müssen die gesalzenen Passwort-Hashes erst implementiert werden, was bei einem Open Source Projekt immer etwas Zeit in Anspruch nimmt.
Zusätzlich muss ein Angreifer ja auch erst mal an die Hash-Werte kommen, die im Normalfall nicht so leicht ausgelesen werden können.
Grüße!
Hallo zusammen,
ich will diesen Thread noch mal aufgreifen, da er doch mit den Anstoß zu einer neuen Passwort-Verschlüsselung für die kommende 2.3 geführt hat. Dort werden nun Salted-Hashs mit mehrfachen Durchläufen genutzt. Dadurch sollte es für Hacker wieder etwas schwieriger werden an die Original-Passwörter heranzukommen, falls die Datenbank mal in falsche Hänge gerät.
Viele Grüße
Fasse
ich will diesen Thread noch mal aufgreifen, da er doch mit den Anstoß zu einer neuen Passwort-Verschlüsselung für die kommende 2.3 geführt hat. Dort werden nun Salted-Hashs mit mehrfachen Durchläufen genutzt. Dadurch sollte es für Hacker wieder etwas schwieriger werden an die Original-Passwörter heranzukommen, falls die Datenbank mal in falsche Hänge gerät.
Viele Grüße
Fasse
