Datendiebstahl: Wie sicher ist die Speicherung der Benutzer-Passwörter in der Joomla-DB

  • Im Zusammenhang mit den Milliarden von Accounts (auch großer Webseitenbetreiber), deren Zugangsdaten gestohlen und in letzter Zeit über das Darknet verscherbelt werden, habe ich die Frage, wie sicher eigentlich die Passwörter in Joomla abgespeichert werden.

    In einem Heise-Artikel lese ich u. a. "...das schon lange als unsicher geltende MD5-Verfahren zum Hashen von Passwörtern...".


    Das führt zu den Fragen:

    • Speichert Joomla 3.9.x die Passwörter auch nur in diesem unsicheren MD5-Verfahren, oder gibt es hier höhere Sicherheitsmaßnahmen? Wenn ja, welche?
    • Ist für Joomla 4.x etwas Sichereres geplant?
    • Gibt es eine Joomla-Programmerweiterung, die die Nutzerpasswörter mit einer sichereren Methode ablegt?
  • IMHO wird MD5 in Verbindung mit Salt eingesetzt.

    Vielleicht hilft Dir der Thread, den man über die Forensuche findet weiter:

    Joomla 3.8.1 Hashwerte Passwörter - wie werden sie erstellt?

    Vielen Dank für den Hinweis.

    Ich gehe mal davon aus, dass es sich dabei nicht nur um Deine Meinung, sondern um einen Fakt handelt - zumindest finden sich in einigen php-Dateien etliche Codezeilen, wo mit md5 und salt hantiert wird

    Dann hoffe ich - als Nichtfachmann - dass dieses Salt die Sicherheit deutlich erhöht und ich beruhigt schlafen kann, auch wenn es mal eine (vermutlich staatliche) Hackergruppe schaffen sollte, die Daten meiner User aus der DB auszulesen.


    Den genannten Thread hatte ich entdeckt, aber weil sich das von Kaukasus beschriebene Vorhabennicht mit meinem Anliegen zu decken schien (und mein Verständnis auch etwas überforderte) habe ich meine Frage hier gestellt.

  • Ich weiss ja nicht was für hochsensible Daten du da hast, aber soweit ich mich erinnere kann man nicht das Passwort auslesen , da

    es nicht abgespeichert wird. weder im Klartext noch verschlüsselt.

    Es werden mit dem eingegebenen Passwort "Berechnungen" angestellt und das Ergebnis abgelegt.

    Dadurch gibt es nicht "das Passwort" sondern viele Passwörter die das selbe Ergebnis ergeben können.


    Ich denke allerdings auch , dass Passwörter eher auf dem Rechner des Users abgegriffen werden als aus einer Foren Datenbank.

    Nur erfahren wir das weniger ;)

  • MD5 ist lediglich als Fallback zu sehen und nicht das Standard-Verfahren in Joomla. Joomla greift, je nachdem, was der Server an Möglichkeiten bietet, auf verschiedene Verfahren zurück.


    Die Sicherheit liefert also primär dein Server und deine eingestellten Passwort-Optionen. Joomla salzt dann die Geschichte noch etwas.


    MD5-Passwörter werden bei erstem Login auch in ein sichereres, nicht-md5, gewandelt.


    Hier ergänzend ein paar Überlegungen bzgl. kommendes Joomla 4: https://github.com/joomla/joomla-cms/pull/23872

  • Ich weiss ja nicht was für hochsensible Daten du da hast,...

    Die denkbar höchstsensiblen: Die Personendaten, die mir meine Nutzer gutgläubig anvertrauen (Name, Nutzername, Emailadresse, Passwort etc.).

    Auf keinen Fall will ich den Nutzern eines Tages mitteilen müssen, dass auch ich als Webseitenbauer und -Betreiber genau so versagt habe, wie schon etliche andere (z.B. Adobe, Dropbox und Konsorten). Weder soll sich einer meiner Nutzer aus Verzweiflung das Leben nehmen, weil er dasselbe Passwort auch für tausend andere Accounts genutzt hatte und jetzt mit unerwünschten Bestellungen unter seinem Namen überschwemmt wird, noch möchte ich vor der Datenschutzbehörde zu Kreuze kriechen und eingestehen, dass ich's einfach nicht drauf hatte. Außerdem weiß ich auch nicht, wo ich das Geld für die Strafzahlung hernehmen soll - und möglicherweise auch noch für den Schadensersatz bei meinen Nutzern.

    Zitat

    aber soweit ich mich erinnere kann man nicht das Passwort auslesen , da

    es nicht abgespeichert wird. weder im Klartext noch verschlüsselt.

    Es werden mit dem eingegebenen Passwort "Berechnungen" angestellt und das Ergebnis abgelegt.

    Dadurch gibt es nicht "das Passwort" sondern viele Passwörter die das selbe Ergebnis ergeben können.

    Wer an die Tabelle "_users" in der Joomla-DB herankommt, dem legen sich sogleich zu Füßen: name, username, email, password (als Hashwert). Die Berechnungen, die angestellt werden, sind einfache logische Vergleiche auf Übereinstimmung oder Nichtübereinstimmung. Dazu geht es gar nicht anders, als dass die Passwörter in der DB abgelegt sind.

    Zitat

    Ich denke allerdings auch , dass Passwörter eher auf dem Rechner des Users abgegriffen werden als aus einer Foren Datenbank.

    Nur erfahren wir das weniger ;)

    Ich habe keinen Überblick, wieviele Milliarden Accounts auf den lokalen PCs der User geklaut wurden, aber dafür bin ich als Admin einer Webseite ja auch nicht verantwortlich.

    Meine Frage entstand nach dem Lesen des Heise-Artikels: "Datenverkauf im Darknet: Nachschlag mit 127 Millionen weiterer Accounts". Siehe unter:

    https://www.heise.de/security/…ren-Accounts-4310778.html


    Ich bedaure die armen Tröpfe, die ihren lokalen PC ausspionieren lassen, weil sie keine Datendisziplin durchhalten können, als da wäre: Lieber 10 E-Mails zu viel als 1 zu wenig gelöscht! Auch bei scheinbar plausiblen Emails von scheinbar bekannten/vertrauten Adressen ist IMMER zuerst Misstrauen angesagt. Dann die Prüfung und ggf. die telefonische Nachfrage beim Absender. Anhänge - wenn überhaupt - dann nur in der Sandbox öffnen. Und Finger weg von Links, die nicht genau da hinführen, wo sie vorgeben hinzuführen. Und - besonders schlimm bei männlichen PC-Nutzern: Verzicht auf den Besuch von Rotlicht, Partnersuch- und Spieleseiten!

    Aber wenn sie das nicht hinkriegen, ist das nicht mein Bier und kostet nicht mein Geld. Ganz anders auf meinen Webseiten ...


    Zugegeben: Die DSGVO nehme ich bierernst.

  • MD5 ist lediglich als Fallback zu sehen und nicht das Standard-Verfahren in Joomla. Joomla greift, je nachdem, was der Server an Möglichkeiten bietet, auf verschiedene Verfahren zurück.

    Das heißt, ich muss beim Provider nachfragen, was genau der Server in Sachen Passwortspeicherung so treibt und Joomla selbst hat nur einen kleinen Anteil (Salt) daran.

    Zitat
    [...]

    Hier ergänzend ein paar Überlegungen bzgl. kommendes Joomla 4: https://github.com/joomla/joomla-cms/pull/23872

    Danke für den Link zu Github.

    Wenn der Google-Translator halbwegs richtig übersetzt hat, dann wird das Thema MD5 / Hash zur Zeit noch heiß diskutiert ...

    Ich bin gespannt!

  • dann wird das Thema MD5 / Hash zur Zeit noch heiß diskutiert

    Nicht wirklich. Es wird nur das Für und Wieder besprochen, WANN man am besten entfernt. Es wird weiterhin klargestellt, dass MD5 und SHA256 und PHPass auf einem aktuellen Server (Zusatz von mir: mit aktuellem PHP) und aktuellem Joomla längst kein Thema mehr sind und "veraltete" Passworte längst automatisch abgehärtet werden (bcrypt) sobald sie genutzt werden.

    Das heißt, ich muss beim Provider nachfragen, was genau der Server in Sachen Passwortspeicherung so treibt und Joomla selbst hat nur einen kleinen Anteil (Salt) daran.

    Jein. Joomla ist gerüstet, mit diversen Hash-Verfahren umzugehen und wählt das stärkste verfügbare, aber wer doof genug ist, seine Seite auf einem Mülleimer-Server zu betreiben oder mit Mülleimer-PHP oder mit Mülleimer-Joomlaversionen, dem hilft dann die Aussage des Mülleimer-Hosters auch nicht mehr, der so etwas zulässt ;)


    EDIT: Und wegen dieser denkbaren Mülleimer-Gegebenheiten "traut" man sich nicht, zu radikal zu arbeiten bzgl. des Entfernens. Weiters muss mindestens 1 Verfahren bestehen bleiben, mit dem man zur Not sich ein vorübergehendes Passwort via Datenbank anlegen kann.

  • Ich muss mich outen: Sobald die Kombination von Programmierkenntnissen und englischer Sprache zusammentrifft, verstehe ich - trotz oder wegen? - Google Translator nur einen Teil des Gesagten und gerate ins Schwimmen.


    In solchen Situationen neigt der Mensch dazu, an eine größere überpersönliche Macht zu glauben, die die Dinge schon richtig lenken wird, wenn er was falsch versteht und Fehler macht. Hier im konkreten Fall neige ich dazu, Deinen letzten Satz im ersten Absatz so auszulegen, dass das, was Joomla 3.9.x in der DB ablegt, etwas durch bcrypt (was immer das schon wieder ist) Abgehärtetes und damit deutlich sicherer als das ursprüngliche MD5 ist.

    Gleichzeitig bleiben meine Augen hängen an "sobald sie genutzt werden". Das heißt doch, dass ich alle Nutzer, die das System in den letzten ***** Monaten oder Jahren nicht mehr genutzt haben, sicherheitshalber rauswerfen muss, weil eben deren Passworte noch nicht gehärtet sind. (Sorry, wenn mein Denken jetzt etwas naiv klingt.)


    Schade, dass man den aktuellen "Härtegrad" unter den vom Server real gegebenen Bedingungen nicht objektiv messen und in Zahlen ausdrücken kann.


    Nachdem ich vor gut 4 Jahren sämtliche von mir betreuten Webseiten nach http://www.all-inkl.com umgezogen habe (meist in den Tarif "Premium"), kann ich also nur hoffen, dass die "Ossis" dort :) mir keine Mülleimer-Server untergejubelt haben - zumindest nicht, wenn PHP 7.2 oder höher eingestellt ist. Gibt es denn irgendwelche bestimmten Servererweiterungen bzw. PHP-Einstellungen die datensicherheitsmäßig "optimal" bzw. völliger "Müll" sind?

    Es wäre einfach zu schön, wenn man alles, was die Datensicherheit betrifft, den Joomla-Systeminformationen möglichst klar und eindeutig entnehmen könnte.

  • Du kannst per phpMyAdmin in die Datenbank gehen. Dort öffnest du die Tabelle, die auf _users endet.

    Solltest du einen finden, dessen "password" mit

    Code
    $1$

    beginnt, ist das ein altes MD5-Passwort. Notier die ID des Users. Sehe im Backend unter den Benutzern nach, was zu diesem Benutzer als "Letzter Besuch" drinnen steht. Dann überlege was ein solcher User mit den ihm zugeordneten Rechten eigentlich anrichten kann, wenn sich wer ein solches Kennwort erschleicht. Ob es sich lohnt da einzuschreiten. Ein Super User, der seit mehreren Jahren nicht mehr angemeldet war, sollte eh gesperrt werden. Der meldet sich dann schon...


    Und mit All-Inkl fährst du gut, soweit du auch dort gute Passwörter verwendest, für was man eben Passwörter verwendet..

  • Du kannst per phpMyAdmin in die Datenbank gehen. Dort öffnest du die Tabelle, die auf _users endet.

    Solltest du einen finden, dessen "password" mit

    Code
    $1$

    beginnt, ist das ein altes MD5-Passwort. Notier die ID des Users. Sehe im Backend unter den Benutzern nach, was zu diesem Benutzer als "Letzter Besuch" drinnen steht. Dann überlege was ein solcher User mit den ihm zugeordneten Rechten eigentlich anrichten kann, wenn sich wer ein solches Kennwort erschleicht. Ob es sich lohnt da einzuschreiten. Ein Super User, der seit mehreren Jahren nicht mehr angemeldet war, sollte eh gesperrt werden. Der meldet sich dann schon...


    Und mit All-Inkl fährst du gut, soweit du auch dort gute Passwörter verwendest, für was man eben Passwörter verwendet..

    Ganz lieben Dank für Deine Hilfestellung.


    Auf die Schnelle habe ich zunächst nur einen Blick auf die DB einer Webseite mit ca. 1500 Nutzern geworfen. Die meisten von Ihnen stammen noch aus Joomla 1.5-Zeiten. Ich hatte sie nach 3.x migriert. $1$ taucht nirgendwo auf. Die meisten beginnen unspektakulär mit irgendwelchen Ziffern oder Zeichen, nicht mit $. Das trifft sowohl auf Nutzer zu, die seit Jahren nicht mehr eingeloggt waren, als auch auf solche, die erst vor kurzem vorbeigeschaut hatten. Ich hoffe mal, dass das ein gutes Zeichen ist.


    Die Admins und der Superuser haben dagegen eine Gemeinsamkeit: Ihre Hashes beginnen alle mit $2y$10$.


    Es geht mir nicht darum, dass ein geklautes Nutzer-Passwort der Webseite Schaden zufügen könnte. Meine Webseiten enthalten m. E. keine solchen Schätze und erst recht keine kompromittierenden oder intimen Daten. Ich möchte die Nutzer selbst davor schützen, dass ihre Passwort-Hashes aus der Joomla-DB gestohlen, durch welche Methoden auch immer in das eigentliche Passwort "reengineert" und schließlich zum Schaden des Nutzers auf diversen anderen Webseiten, wo der Nutzer dasselbe PW verwendet (insbesondere Onlineshops, asoziale Netzwerke u. ä.) zur Vortäuschung der Identität missbraucht werden.

  • Die meisten beginnen unspektakulär mit irgendwelchen Ziffern oder Zeichen, nicht mit $.

    Das sollten sie aber. Ich würde für diese User, vielleicht sogar für alle, eine Paswwort-Rücksetzung einstellen. Das kann man mit dem Knopf Benutzer > "Stapelverarbeitung" sehr leicht machen. Sie melden sich mit Ihrem alten Kennwort an und werden sofort aufgefordert ein neues zu vergebn, was dann mit Sicherheit "gedollart" wird, selbst, wenn sie das alte erneut eingeben (wobei ich nicht ausprobiert habe, ob das bei der Rücksetzung erlaubt ist).


    Du kannst unter Benutzer > Optionen > zuvor die Passwortoptionen etwas oder mehr hochschrauben. Mindestens 12 Zeichen sollten es schon sein. Leider hat Joomla nichts drinnen, wie z.B. MediaWiki, um "Blödeimer"-Kennworte zu verhindern. 1234 oder Passwort = Username etc. pp.


    Ich habe das nämlich mal getestet

    und "veraltete" Passworte längst automatisch abgehärtet werden (bcrypt) sobald sie genutzt werden.

    Ich habe mir per Datenbank ein MD5-Passwort angelegt, also "beginnend unspektakulär mit irgendwelchen Ziffern oder Zeichen", und wider Erwarten wurde es bei Erstnutzung nicht abgehärtet, sondern blieb unverändert, und auch nach neu speichern des Profils. Nur, wenn ich im Profil das Passwort erneut eingebe und speichere wird "gedollart".


    Also Entschuldigung für diese Fehlinformation! Ich war fest davon ausgegangen, auch nachdem ich diesen Dialog auf GitHub gelesen hatte.

  • Keine Ursache! Manchmal muss man einem anderen etwas erklären, um dabei auch für sich selbst neue Erkenntnisse zu gewinnen. Und dann sind so Typen wie ich nützlich, die die entsprechenden Fragen stellen. Das habe ich selbst - in anderen Zusammenhängen - auch immer wieder erlebt.


    Aufgrund Deines zweiten Absatzes habe ich gerade mal gegoogelt und stieß auf "FPC Force Password Complexity" von Kubik Rubik . Ich werde es mal ausprobieren.


    Und das mit der Passwort-Rücksetzung (Absatz 1) für alle ist mir gar nicht so unlieb. Danach hätte ich zumindest das gute Gefühl, jetzt auf der "sicherstmöglichen Seite" zu liegen. Aber da muss ich noch in Ruhe drüber nachdenken, wie ich es den Nutzern verkaufen kann. Viele von ihnen gehören schon zu den älteren Semestern (wie ich selbst ja auch). Und manche von ihnen mögen nicht mehr so viele Veränderungen in ihrem Leben - ihnen ist der kindliche Explorationsdrang abhanden gekommen.

  • Noch ein kurzer Sachinput hierzu:


    Joomla hat in seiner Historie insgesamt 5 verschiedene Techniken zum Speichern von Passwörtern verwendet.


    1. MD5 ohne Salt - das betraf, wenn ich mich recht entsinne, die 1.0er und frühen 1.5er Versionen


    2. MD5 mit Salt in eigenem Format - das betrifft die 1.5er und 2.5er Releases. An den Hash des Passworts wurde, durch ein Doppelpunkt getrennt, der Klartext Salt angehangen


    3. MD5 mit Salt im /etc/passwd Format. Das betrifft, wenn ich mich richtig erinnere, J 3.0 und 3.1 - das sind die Hash’s die mit $1$ anfangen


    4. SHA256 oder bcrypt beide mit Salt. Das ist der Stand von Joomla 3.2 und war die einzige Version, in der der Algorithmus vom Server abhing. „Gute“ PHP Versionen (5.3.10 oder neuer) hatten bcrypt, ältere Versionen haben mit sha256 gearbeitet.


    5. bcrypt via Phpass bzw. password_hash - das ist der aktuelle Standard der mit vertretbarem Aufwand und bei gescheiten Passwörtern nicht zu knacken ist. Ist ab Joomla 3.3 aktiv.

  • Ich habe mir per Datenbank ein MD5-Passwort angelegt, also "beginnend unspektakulär mit irgendwelchen Ziffern oder Zeichen", und wider Erwarten wurde es bei Erstnutzung nicht abgehärtet, sondern blieb unverändert, und auch nach neu speichern des Profils. Nur, wenn ich im Profil das Passwort erneut eingebe und speichere wird "gedollart".


    Also Entschuldigung für diese Fehlinformation! Ich war fest davon ausgegangen, auch nachdem ich diesen Dialog auf GitHub gelesen hatte.

    Ich habe das heute noch mal probiert und es klappt doch. War ich gestern wohl zu müde. Also nach 1. Login wird das MD5-Passwort automatisch im Hintergrund "abgehärtet". PHP7.

  • Ich habe das heute noch mal probiert und es klappt doch. War ich gestern wohl zu müde. Also nach 1. Login wird das MD5-Passwort automatisch im Hintergrund "abgehärtet". PHP7.

    Kann passieren - gibt Schlimmeres!


    *****************

    Zwischenzeitlich habe ich festgestellt, dass Joomla ja selbst unter Benutzer > Optionen > Passwortoptionen die Möglichkeit bietet, eindeutige und schärfere PW-Vorgaben zu machen.

    Und das o. g. FPC Plugin trägt weiteres dazu bei. Z. B.:


    "Warnung

    Das Passwort hat zu wenige Zahlen! Es muss mindestens 2 Zahlen enthalten!

    Das Passwort hat zu wenige Sonderzeichen! Es muss mindestens 2 Sonderzeichen enthalten!

    Das Passwort hat zu wenige Großbuchstaben! Es muss mindestens 1 Großbuchstaben enthalten!

    Das Passwort ist zu kurz! Passwörter müssen mindestens aus 8 Zeichen bestehen!

    Ungültiges Feld: Passwort"


    und


    "Nachricht

    Das Passwort wurde akzeptiert, jedoch vom System als schwach eingestuft. Zur eigenen Sicherheit sollte ein neues, stärkeres Passwort gesetzt werden. Folgende Punkte sind beim aktuellen Passwort aufgefallen:
    Das gewählte Passwort ist kurz. Es sollten mindestens 8 Zeichen verwendet werden.
    Die Komplexität des Passworts ist gering. Es sollte ein komplexeres Passwort verwendet werden.
    Das Passwort sollte nicht so viele gleiche aufeinanderfolgende Zeichen beinhalten.

    Benutzer gespeichert!"


    Wenn ich meinen Nutzern die Neuvergabe Ihrer Passwörter zumute, werde ich dieses FCP gleich im Feldversuch testen (und hoffentlich keine allzu große Verärgerung auslösen, weil sich keiner mehr sein PW merken kann).

  • Deutlich wichtiger als komplexe Passwörter sind einzigartige Passwörter, daher kann das hier eine sinnvolle Ergänzung sein:

    https://extensions.joomla.org/extension/hibp/

    Bevor es hier Bedenken gibt, dass da Passwörter an einen Drittservice gehen:

    Es werden die (wertlosen) ersten 5 Stellen des Hashes an den Service geschickt und dann in der Antwort nach einem Match gesucht - es fließen also keine Daten ab.

  • Danke für den Hinweis auf das HIBP-Plugin. Ich werde es testen.

    Was mich aber etwas nachdenklich macht, ist der Hinweis in der (übersetzten) Doku:


    Wenn Sie das Plugin während der Anmeldung auslösen, wird das gesamte Formular gelöscht. Der Benutzer muss also alles neu eingeben, nicht nur das Kennwort. Das ist ärgerlich, reicht aber für eine erste Veröffentlichung aus.
    Falls die API fehlerhaft oder offline ist, schlägt das Plug-In automatisch fehl und erlaubt die Verwendung des Kennworts.
    Die API reagiert im Allgemeinen sehr schnell, aber es kann vorkommen, dass die Antwort verzögertwird, insbesondere in dem Szenario, in dem das System ein Timeout von der
    API-Anforderung erhält.
    Eine mögliche zukünftige Verbesserung besteht in der Ausgabe von Warnungen für Kennwörter, die gefährdet sind, aber über die Option "Max Compromises" zulässig sind. Der
    Benutzer kann sein Kennwort haben, wird jedoch gewarnt, dass es möglicherweise unsicher ist.


    Ich kenne mich ja selbst und meine Ungeduld: Wenn ich irgendein Online-Formular ausfülle, schon fast fertig bin und dann aus irgendeinem Grund das Formular plötzlich wieder komplett leer ist, dann macht mich das so sauer ("...mal wieder kostbare Lebenszeit vergeudet...":cursing:), dass ich in solchen Fällen des öfteren schon ganz auf die weitere Nutzung der entsprechenden Webseite verzichtet und mich nicht registriert habe. Da kann ich mir gut vorstellen, dass es anderen ganz ähnlich geht.