Difference between revisions of "Changes to the 2FA token generation recommendations for existing sites/de"

Latest revision as of 13:29, 4 March 2021

Other languages:

Deutsch • ‎English

Diese Seite enthält Details zu den mit Joomla 3.9.25 veröffentlichten Sicherheitspatches hinsichtlich der Einrichtung von 2FA (Zwei-Faktor-Autorisierung). Hier findet man eine Analyse der Auswirkungen und auch Empfehlungen für bestehende Seiten.

Berichtete Fehler

Das JSST (Joomla! Security Strike Team) wurde von dem Sicherheitsforscher Hanno Böck kontaktiert und auf zwei Probleme im Code aufmerksam gemacht, die durch dieses Update behoben wurden.

Betroffene Versionen

Allgemeine Informationen

Die Ursache ist

Seit Joomla 3.2.0 wird der Joomla-Kern mit einer 2FA / TOTP-Unterstützung versehen. Bis zur Version 3.9.25 hatte die Implementierung zwei kleinere Sicherheitslücken:

Einsatz der unsicheren Funktion rand() innerhalb des Prozesses zur Erzeugung des 2FA-Geheimschlüssels.
Anwenden einer zu geringen Länge für den 2FA-Geheimschlüssel von 10 Bytes gegenüber 20 Bytes nach RFC 4226.

So wurde das Problem behoben

Ab Joomla 3.9.25 wurde die Implementierung des Joomla-Kerns aktualisiert:

Verwenden einer sicheren Zufallsfunktion (random_int; von der Bibliothek paragonie/random_compat in ältere PHP-Versionen zurückportiert).
Verwenden von 20 Bytes statt des alten Wertes von 10 Bytes, um den 2FA-Geheimschlüssel zu generieren.

Dieses Problem wurde mit Akeeba Ltd. abgestimmt, da sie die ursprüngliche FOF-Codebasis für den Kern beigesteuert haben.

Hat dies Auswirkungen auf meine Website

Wie im ursprünglichen Bericht von Hanno Böck beschrieben, sagte er hinsichtlich der Verwendung der unsicheren rand-Funktion:

[...] Ich schätze das praktische Risiko hierfür als gering ein. Um dies anzugreifen, müsste ein Angreifer den ungefähren Zeitpunkt kennen, zu dem die Person ihren TOTP-Geheimschlüssel erstellt hat. Intern verrechnet PHP in Mikrosekunden zweimal, sodass man die möglichen Optionen für den Schlüssel vielleicht auf ein paar Millionen reduzieren könnte, was für einen echten Angriff immer noch sehr wenig praktikabel ist. [...]

Und für die Verwendung von 10 gegenüber 20 Bytes sagte er Folgendes:

[...] Der Code verwendet standardmäßig 10 Bytes für den Geheimcode. 10 Byte sind 80 Bit. Das Risiko ist hier gering. 80 Bits sind immer noch außerhalb jedes praktikablen Angriffs. Dennoch denke ich, dass die Sicherheitsanforderungen (und sogar Empfehlungen) des RFC befolgt werden sollten, daher empfehle ich, dies auf 20 Byte (aka 160 Bit) zu ändern. [...]

Basierend auf diesen Informationen kam das JSST zu dem Schluss, die Änderungen wie oben beschrieben zu implementieren. Dies bedeutet jedoch ausdrücklich nicht, dass praktisch alle 2FA-Token, die vor dem Patch generiert wurden, neu generiert werden müssten, da sie immer noch wie erwartet funktionieren und aus einer praktischen Sicht immer noch sicher sind. Es sollte auch klar sein, dass die hier vorgenommenen Änderungen nur solche Geheimschlüssel betreffen, die nach dieser Änderung erzeugt wurden.

@@ Line 28: / Line 28: @@
 [...]
-''I consider the practical risk of this to be low. In order to attack this an attacker would have to know the approximate time when the
+''Ich schätze das praktische Risiko hierfür als gering ein. Um dies anzugreifen, müsste ein Angreifer den ungefähren Zeitpunkt kennen, zu dem die Person ihren TOTP-Geheimschlüssel erstellt hat. Intern verrechnet PHP in Mikrosekunden zweimal, sodass man die möglichen Optionen für den Schlüssel vielleicht auf ein paar Millionen reduzieren könnte, was für einen echten Angriff immer noch sehr wenig praktikabel ist.''
-person created his TOTP secret. PHP internally mixes in microseconds twice, so one could maybe reduce the possible options for the key to a few million, which is still very impractical for a real attack.''
 [...]
-And for the usage of 10 vs 20 bytes he said the following:
+Und für die Verwendung von 10 gegenüber 20 Bytes sagte er Folgendes:
 [...]
-''The code by default uses 10 bytes for the secret. 10 bytes is 80 bits. The risk here is low. 80 bits is still outside of any practical attack. Nevertheless I think security requirements (and even recommendations) of the RFC should be followed, so I recommend changing this to 20 bytes (aka 160 bits).''
+''Der Code verwendet standardmäßig 10 Bytes für den Geheimcode. 10 Byte sind 80 Bit. Das Risiko ist hier gering. 80 Bits sind immer noch außerhalb jedes praktikablen Angriffs. Dennoch denke ich, dass die Sicherheitsanforderungen (und sogar Empfehlungen) des RFC befolgt werden sollten, daher empfehle ich, dies auf 20 Byte (aka 160 Bit) zu ändern.''
 [...]
-Based on that information the JSST came to the conclusion to obviously implement the changes as note above but this does explicite not mean that practically all 2FA tokes generated prior the patch have to be regenerated as they still work as expected and are still secure form a practical standpoint.
+Basierend auf diesen Informationen kam das JSST zu dem Schluss, die Änderungen wie oben beschrieben zu implementieren. Dies bedeutet jedoch ausdrücklich nicht, dass praktisch alle 2FA-Token, die vor dem Patch generiert wurden, neu generiert werden müssten, da sie immer noch wie erwartet funktionieren und aus einer praktischen Sicht immer noch sicher sind.
-It should also be obvious that the changes made here only affect secrets generated after this change.
+Es sollte auch klar sein, dass die hier vorgenommenen Änderungen nur solche Geheimschlüssel betreffen, die nach dieser Änderung erzeugt wurden.
 __NOTOC__

J3.x