Skip to content

Zweiter Faktor

Ein TOTP-kompatibler zweiter Faktor kann pro Mandant aktiviert werden. Der CMI STS implementiert den Standard RFC 6238.

Wenn ein externer Identity Provider verwendet wird, sollte der zweite Faktor von diesem externen Identity Provider durchgeführt werden und nicht durch den CMI STS.

Der zweite Faktor kann mit der Option Totp aktiviert werden, wenn der externe Identity Provider nicht in der Lage ist einen zweiten Faktor durchzuführen oder wenn das BuiltIn-Login verwendet wird.

Die Benutzer benötigen eine App die das TOTP-Protokoll unterstützt. Beispielsweise den Authenticator von Google oder Microsoft. Siehe HowTo 2FA Registration

Der einzige erforderliche Parameter ist das Secret, welches aus einer zufälligen und beliebigen Zeichenfolge besteht. Wenn das Secret einem Angreifer bekannt ist, ist es möglich den zweiten Faktor zu berechnen. Daher gilt es, das Secret zu schützen.

{
    "tenants": {
        "<tenant>": {
            "Totp": {
                "Secret": "<eine zufaellige Zeichenfolge>",
                "..." // weitere optionale Einstellungen
                "VerificationWindow": { // "Clock drift" Einstellungen
                    "Previous": 1,
                    "Future": 1
                }
            }
        }
    }
}

Es gibt weitere optionale Einstellungen, die einen Standardwert haben. Es gibt Authenticator-Apps, die nur die Standardeinstellungen unterstützen und daher nicht funktionieren, wenn die optionalen Einstellungen überschrieben werden.

Beispiel: Angenommen die Anzahl der Ziffern für den zweiten Faktor wird von 6 auf 8 erhöht, dann wird der TOTP-App diese Einstellung zwar mitgeteilt, aber nicht jede TOTP-App reagiert auf diese Einstellung und produziert weiterhin nur 6 Ziffern. Ihre Ziffernfolgen sind dann also ungültig.

Einstellung Beschreibung Standard
HashMode Verwendetes Hashverfahren: Sha1,Sha256,Sha512 Sha1
StepSec Intervall in Sekunden, in dem neue Ziffernfolgen generiert werden (Siehe auch VerificationWindow). 30
Digits Länge der Ziffernfolge, die der Benutzer eingeben muss. (RFC 6238: 8, De facto: 6) 6
VerificationWindow.Previous Anzahl der abgelaufenen Ziffernfolgen, die noch akzeptiert werden. 1
VerificationWindow.Future Anzahl der zukünftigen Ziffernfolgen, die bereits akzeptiert werden. 1

Das VerificationWindow kann erhöht werden, wenn eine hohe Zeitdrift zwischen den lokalen Uhren der Benutzer-Endgeräte und dem CMI STS besteht.

Achtung: Das Ändern von TOTP-Einstellungen (mit Ausnahme des VerificationWindow) kann die Ziffernfolgenerzeugung der bereits eingerichteten TOTP-Apps invalidieren. Daher muss der zweite Faktor für jeden Benutzer zurückgesetzt werden und der Benutzer muss den zweiten Faktor erneut einrichten.

Migration des zweiten Faktors vom STS 2.x

Der STS 2.x und der STS 3.x erzeugen nicht dieselben Codes für einen Benutzer, auch wenn das selbe Basis-Secret konfiguriert wird.

Bei einem Update vom STS 2.x auf den 3.x muss der zweite Faktor für alle Benutzer zurückgesetzt werden. Das kann mit einer Massenänderung im CMI erfolgen.

Das Secret für einen Benutzer wird jeweils folgendermassen erzeugt:

STS 2.x: * Das Secret wird zusammengesetzt aus <Basis-Secret aus der Konfiguration>:<Benutzer-Claim 'user_guid'>, Base62 codiert und als Benutzer-Secret verwendet.

STS 3.x: * Das Basis-Secret aus der Konfiguration wird als Byte-Folge interpretiert byte[]. * Die Zeichenfolge CMI <Mandantenname in Versalien>:<Benutzer-Claim 'fullname'> wird erzeugt und als Byte-Folge interpretiert. * Ein HMAC-Hash wird aus beiden Byte-Folgen erzeugt, Base32 codiert und als Benutzer-Secret verwendet.

OTP Selektoren

Wenn Topt für einen Mandanten konfiguriert wird, wird der zweite Faktor bei jeder Anmeldung angefordert.

Mittels OTP Selektoren ist es möglich, den zweiten Faktor unter bestimmten Bedingungen zu überspringen.

{
  "tenants": {
    "hauptmandant": {
      "Totp": {
        "Secret": "<secret>"
      },
      "OtpSelectors": [
        {
          "NetworkRanges": [
            "127.0.0.0/8",
            "::1/128"
          ],
          "Clients": ["metatool"],
          "Providers": ["metatool"],
          "SecondFactorEnabled": false
        },
        {
          "NetworkRanges": ["10.8.10.0/24"],
          "Clients": ["metatool"],
          "SecondFactorEnabled": false
        }
      ]
    }
  }
}

Die Selektoren werden in der Reihenfolge ihrer Deklaration überprüft. Der erste zutreffende Selektor wird verwendet. Daher sollen spezifische Selektoren vor unspezifischen Selektoren stehen.

Wenn keine Selektoren vorhanden sind, oder kein Selektor zutrifft, wird der zweite Faktor angefordert.

Ein Selektor kann auf folgende Eigenschaften einer Anmeldung reagieren:

  • NetworkRanges (optional): Eine Liste von IP-Adress-Bereichen nach der CIDR-Notation 0.0.0.0/0 / 0:0:0:0:0:0:0:0/0, auf die der Selektor beschränkt ist. Wenn der CMI STS hinter einem Proxy betrieben wird, müssen die Forwarded Headers konfiguriert werden, damit die IP-Adresse des Clients ausgewertet wird, und nicht die des Proxies.
  • Providers (optional): Eine Liste von Identity Providern auf den der Selektor beschränkt ist. Der Provider metatool bezeichnet das lokale Login beim CMI (BuiltIn-Login).
  • Clients (optional): Eine Liste von ClientId's auf die der Selektor beschränkt ist. Achtung: Ein Client-Id-Selektor sollte nur zum Einsatz kommen, wenn die Client-Id fälschungssicher ist (RFC 7636 - Proof Key for Code Exchange (PKCE)). Ansonsten kann der Client eine beliebige Client-Id angeben und so den zweiten Faktor deaktivieren. Der Implicit Grant Flow ist anfällig für diesen Angriffsvektor.
  • SecondFactorEnabled (optional, Standardwert: true): Wenn false, wird der zweite Faktor nicht angefordert, wenn der Selektor aktiviert wird.

Das Debug-Log gibt darüber Auskunft, welcher Selektor aktiviert wurde.