Sicherheitsfunktionen auswählbar machen

  • Warum bestehen bei der E-Mail Funktion Bedenken?

    Sobald du Zugriff auf das E-Mail-Postfach hast, kannst du alles machen.

    Der zweite Faktor landet in dem E-Mail-Postfach.

    Die Passwort-Vergessen-Mail landet in dem Postfach.

    Nutzt du TOTP oder WebAuthN, brauchst du Zugriff auf das Postfach UND den zweiten Faktor.

  • Das kommt darauf an, ob derjenige zufällig mit dem gleichen Gerät und Browser (+ Version) wie du es nutzt, um die Ecke sitzt und sich mit deinen Daten anmeldet. Denn wenn der Ort nicht passt, der Rest aber schon, würde ich mir noch keine Gedanken machen. Ich denke, wenn man den Usern erklärt, was sie aus der E-Mail entnehmen können und wie sie prüfen können, ob sie das selber waren, dann macht es durchaus Sinn (z.B. Wie ist meine IP?). Aber es wäre sicherlich wünschenswert, dass das jeder Admin für sein Forum selber entscheiden kann. Ist ja aber wohl schon abgewählt :( . Die Geräteverifizierung würde ich persönlich nie abschalten, nur, weil der Ort nicht 100 % passt. Aber mit der E-Mail, das stimmt schon.

    Liebe Grüße
    Susi

    • Offizieller Beitrag

    Hallo,

    neben der – selbstverständlich – sicheren Implementierung der Mehrfaktor-Authentifizierung, lag unser Hauptaugenmerk bei der Entwicklung dieser Funktionalität auf einer leicht verständlichen und benutzerfreundlichen Implementierung. Wir haben ausgiebig über den Workflow für den Benutzer diskutiert und dabei sowohl unsere langjährige Erfahrung in der Entwicklung von Webanwendungen, als auch die Implementierung bei Diensten die ein Laie typischerweise kennt als Basis genommen. Zu letzteren gehörten insbesondere Google und Facebook.

    Die fehlende Konfigurierbarkeit der Mehrfaktor-Authentifizierung ist dabei eine bewusste Entscheidung gewesen. Uns ist es wichtig, dass sich unsere Software in Bezug auf eine derartige Sicherheitsfunktion in jeder Community (und auch Dienste-übergreifend) identisch verhält, damit der Nutzer sich am Ende an bekannten Abläufen orientieren kann und dadurch ein Gefühl von Vertrautheit bekommt. Das reduziert menschliche Fehler, die die Hauptgründe für „geknackte“ Benutzerkonten sind.

    Da hier offenbar noch einige Verwirrung herrscht und die Diskussion auch ein wenig in die Benutzerfreundlichkeit von bestehenden Plugins abgedriftet ist, möchte ich an dieser Stelle noch einmal die Hintergründe unserer Entscheidungen ein wenig näher erklären.

    WebAuthn

    Die Integration von WebAuthn wird nicht Bestandteil des Standardumfangs sein. Hauptgrund dafür ist, dass WebAuthn besondere technische Anforderungen an den Server bzw. Webspace stellt und dass Fehler des Administrators dazu führen, dass bereits registrierte Sicherheitsschlüssel des Benutzers unbrauchbar werden. Letzteres ist nun wirklich keine gute Benutzererfahrung.

    WebAuthn erfordert zur Registrierung und Verifizierung von Sicherheitsschlüsseln PHP-Extensions (gmp), die nicht auf jedem Webspace installiert sind. Nach einem Serverumzug kann es möglich sein, dass diese Extension nicht mehr zur Verfügung steht. Das verunmöglicht dann den Login für betroffene Nutzer.

    Darüber hinaus verunmöglicht jeder Umzug auf eine andere Domain den Login mit Sicherheitsschlüsseln die bereits registriert sind. Der größte Vorteil von WebAuthn gegenüber allen anderen Mehrfaktor-Verfahren ist die Tatsache, dass Sicherheitsschlüssel bei der Registrierung an die Domain der Website gebunden werden. Auf diese Weise werden Phishing-Attacken unmöglich, da die Domain der Phishing-Seite nicht passt und der Sicherheitsschlüssel daher keine gültigen Daten ausspuckt. Ein „Smartphone App“ (TOTP)-Code könnte durch eine Phishing-Seite einfach abgefragt werden und müsste lediglich innerhalb von etwa 90 Sekunden eingelöst werden. Ein Domain-Umzug kann nicht von einer Phishing-Seite unterschieden werden. Deswegen muss man sich für eine Domain entscheiden, die man dauerhaft verwenden möchte.

    Unser WebAuthn-Plugin erkennt solche Domain-Umzüge aktiv und zeigt eine Warnmeldung in der Verwaltung der Sicherheitsschlüssel an:

    Da WebAuthn aber nicht Bestandteil des Standardumfangs ist, sieht die „Benutzerkonto-Sicherheit“-Seite standardmäßig wie folgt aus:

    Zwei Verfahren, eines davon das allbekannte TOTP-Verfahren („Smartphone App“) und das E-Mail-Verfahren. Das dürfte selbst den sprichwörtlichen „DAU“ nicht überfordern.

    Mit der Installation des WebAuthn-Plugin kommt dann der „Sicherheitsschlüssel“-Punkt hinzu. Wir können jedem Administrator, der sich den zuverlässigen Betrieb auf technischer Basis zutraut (d.h. die Unterstützung durch den Server und die Verwendung einer stabilen Domain) nur empfehlen, das WebAuthn-Plugin einzusetzen. Das mag auf den ersten Blick vielleicht kompliziert aussehen, weil man das Verfahren noch nicht kennt. Es ist aber das wohl benutzerfreundlichste Verfahren und gleichzeitig das mit Abstand sicherste Verfahren. Die Verwendung eines physischen Sicherheitsschlüssels ist dafür auch gar nicht von Nöten. Windows, macOS, iOS und Android haben jeweils native Unterstützung auf Basis des integrierten Keyrings. Falls man einen physischen Sicherheitsschlüssel verwenden möchte, dann muss es auch kein teurer YubiKey sein. Es gibt günstige „FIDO2“-Keys ohne NFC-Unterstützung bei Amazon ab etwa 10€. Mit NFC ist man bei etwa 20€. Diese Sicherheitsschlüssel können dann auch bei anderen Diensten wie Google oder Dropbox verwendet werden.

    E-Mail-Codes

    MysteryCode hat den Nachteil des Verfahrens bereits korrekt erklärt: Es bietet im schlechtesten Fall keinen Sicherheitsvorteil. Aber nicht jeder Fall ist der schlechteste Fall. Wenn das E-Mail-Konto ein anderes Kennwort benutzt, dann ist man besser geschützt. In vielen Fällen ist ein Diskussionsforum im Falle eines gehackten E-Mail-Kontos das kleinste Problem eines Nutzers.

    Die E-Mail-Codes sind gleichzeitig auch ein Ersatz für die zuvor bereits diskutierten Gerätebestätigungen durch das Plugin von Hanashi und bieten ein ähnliches, bzw. leicht besseres Sicherheitsniveau. Die versendeten E-Mails sehen auf den ersten Blick vielleicht nicht so hübsch und informativ aus, aber auch das ist eine bewusste Entscheidung gewesen. Wie bereits festgestellt wurde, ist die Angabe des Ortes in vielen Fällen äußerst unpräzise und sorgt für Verunsicherung beim Benutzer, auch wenn alles okay ist. Das führt dazu, dass etwaige Warnmeldungen im Zweifelsfall nicht mehr ernst genommen werden. Darüber hinaus enthält die E-Mail keinen Bestätigungslink. Die Bestätigung muss über Eingabe eines Codes erfolgen. Grund dafür ist, dass man nicht durch einen versehentlichen Klick auf einen Link dafür sorgt, dass ein tatsächlich unerwünschter Login durchgeführt werden kann. Der Code muss aktiv aus der E-Mail kopiert oder abgeschrieben werden. Um das zu erleichtern ist der Code direkt an erster Stelle im Betreff platziert. So kann dieser beispielweise bequem aus einer Benachrichtigung abgeschrieben werden, ohne die E-Mail komplett öffnen zu müssen.

    Fazit: Viele der Dinge, die auf den ersten Blick merkwürdig, kompliziert oder verwirrend wirken, haben gute Gründe dafür, dass sie so sind, wie sie sind. Durch die fehlenden Einstellungsmöglichkeiten nehmen wir dem Administrator die Arbeit ab, sich im Detail darüber informieren zu müssen. So hat dieser mehr Zeit, sich um das Wesentliche zu kümmern: Die Inhalte der eigenen Community.

    Gerne nehmen wir aber Feedback zu beispielsweise den Hilfetexten an, falls in der Praxis doch noch etwas unklar sein sollte.

  • Danke für die ausführliche Erklärung :)

    „If you can only do one thing, hone it to perfection. Hone it to the utmost limit!“ – Zenitsu Agatsuma

  • Ich kann genauso nur raten, aber mit der LDAP-Anbindung sowie elasticsearch-Integration gibt es ja schon zwei offizielle Plugins, die jeweils 100 Euro kosten. Daher würde ich persönlich erst einmal mit einem Preis in dieser Region rechnen. Aber eine offizielle Aussage zum Preis wird es vermutlich erst geben, sobald es eine offizielle Ankündigung dazu gibt. Anfang März stand der Preis jedenfalls noch nicht fest, ausgehend von einem Kommentar von Marcel Werk im Blog-Artikel über die 2FA-Unterstützung.

    Einmal editiert, zuletzt von Cadeyrn (12. Mai 2021 um 15:38) aus folgendem Grund: Wort vergessen

  • Wobei WebAuthn gerade durch die native Integration in beispielsweise das Apple-Ökosystem äußerst bequem ist.

    Das ist aber nur auf dem Mac nutzbar und nicht auf dem iPhone (mit FaceID) oder?
    Habe es gestern eingerichtet auf dem MacBook aber auf dem iPhone wartet er auf einen Sicherheitsschlüssel, also einen Yubikey o.ä. wenn ich es richtig verstehe. Auf dem MBP hat er einfach Touch ID genutzt daher dachte ich, dass er bei iOS einfach Face ID nutzt, da Touch ID nicht vorhanden ist.

    • Offizieller Beitrag

    Das ist aber nur auf dem Mac nutzbar und nicht auf dem iPhone (mit FaceID) oder?

    Es ist sowohl mit dem MacBook und TouchID nutzbar, als auch mit TouchID oder FaceID auf dem iPhone.

    Auf dem MBP hat er einfach Touch ID genutzt daher dachte ich, dass er bei iOS einfach Face ID nutzt, da Touch ID nicht vorhanden ist.

    Wichtig ist hier zu verstehen, dass der Schlüssel, den du mit TouchID bzw. FaceID hinterlegst einzigartig pro Gerät ist. Das bedeutet, du musst alle Geräte hinterlegen, um dich damit anzumelden (sprich: einmal das Handy und einmal den Laptop). AFAIK kann der Schlüssel auch nicht, bei Verlust des Gerätes, aus einem Backup wiederhergestellt werden.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!