QR-Codes für TOTP-Secrets erstellen

Im Artikel Zwei-Faktor-Authentisierung für OpenSSH und OpenVPN wurde ein einfacher Weg vorgestellt, die Sicherheit PAM-fähiger Dienste durch eine Zwei-Faktor-Authentisierung zu erhöhen. Bei dem verwendeten TOTP-Verfahren wird auf Grundlage eines Shared Secret ein zeitlich begrenzt gültiges Einmalpasswort erzeugt.

Je nach Verfahren und Kodierung besteht das Shared Secret aus 32 oder gar 40 Zeichen, die dem Benutzer mitgeteilt werden müssen. Als bequeme und fehlertolerante Lösung haben sich hierzu QR-Codes etabliert, die mit geeigneten Apps eingelesen werden können. Diese QR-Codes enthalten jedoch häufig noch weitere, überflüssige Informationen, die Rückschlüsse auf den Account zulassen.

Dieser Artikel wirft einen Blick auf den Aufbau des Inhalts solcher QR-Codes und wie diese dennoch sicher eingesetzt werden können.

Fallstricke

In seinem Artikel Why you shouldn’t scan two-factor authentication QR codes konstruiert Sam Aiken interessante Szenarien und rät von der unbedachten Nutzung von QR-Codes zur Übermittlung des Shared Secret bei 2FA ab.

Neben dem Shared Secret enthalten die meisten QR-Codes auch Informationen zum Dienstbetreiber, dem Dienst selbst und Benutzernamen. Gelangt ein Angreifer an diese Informationen – sei es durch den QR-Code selbst oder weil die verwendete App ihre Daten ungesichert lokal oder in der Cloud abspeichert oder diese anderweitig verliert – muss er nur noch das Passwort des Accounts herausbekommen, um den Dienst unter falschem Namen nutzen zu können.

Dem Benutzer steht es natürlich frei diese Zusatzinformationen zu löschen oder abzuändern, laut Aiken sei dies jedoch nicht in allen Apps möglich: einige Apps erlaubten keine Veränderungen, andere Apps böten zwar die Möglichkeit Änderungen vorzunehmen, merken sich jedoch die ursprünglich eingelesenen Werte, sodass auch hier unnötig Informationen preisgegeben werden könnten. Aiken bemängelt außerdem, dass viele Dienste lediglich QR-Codes anzeigten, nicht jedoch das Shared Secret als Zeichenfolge, was dem Benutzer selbst die volle Kontrolle über die Daten gäbe, die in eine App eingetragen werden.

Neben dem Einsatz einer in dieser Hinsicht empfehlenswerten App wie andOTP, deren Verwendung Admins zwar beeinflussen, jedoch nicht immer vorschreiben können, wäre es daher wünschenswert, wenn QR-Codes von vornherein ohnehin nur die essentiellen Informationen enthielten.

URI-Schema

Der Inhalt eines solchen QR-Codes entspricht letztendlich einer URI, wie Google sie beispielsweise für seine Authenticator-App auf Github definiert hat:

otpauth://TYPE/LABEL?PARAMETERS

Der Platzhalter TYPE gibt dabei an, ob es sich bei dem verwendeten Verfahren um HOTP oder wie in unserem Fall um TOTP handelt, LABEL soll laut Spezifikation Informationen zum Aussteller und Benutzerkonto enthalten, PARAMETERS kann neben dem erforderlichen secret noch weitere Informationen enthalten.

Von allen aufgeführten Optionen werden laut Spezifikation für TOTP lediglich TYPE, LABEL und der PARAMETER secret benötigt.

Mit diesen Informationen ist es uns nun möglich eine URI für das im letzten Artikel für die Benutzerin Alice erzeugte Shared Secret zu erstellen. Aus Datensparsamkeit wird hier beim Label lediglich der Dienst angegeben. Sollte Alice weitere Informationen zum Dienst benötigen, so können Ihr diese auch auf anderem Wege mitgeteilt werden.

otpauth://totp/OpenVPN?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75

Die in dieser URI enthaltenen Informationen erlauben keinen Rückschluss auf den Betreiber, die Adresse oder den verwendeten Benutzernamen des angegebenen Dienstes. Dies sollte für die meisten Anwendungsfälle ausreichend sicher sein.

Versuche mit andOTP ergaben darüber hinaus, dass der Abschnitt LABEL einer URI auch komplett leer gelassen und dennoch problemlos eingelesen werden kann:

otpauth://totp/?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75

QR-Code erzeugen

Um die soeben erzeugte URI in einen QR-Code umzuwandeln, bietet sich das Kommandozeilentool qrencode an. Die Codes können in eine Bilddatei geschrieben oder aber auch direkt als ASCII-Art auf der Kommandozeile angezeigt werden:

$ qrencode -t ANSI 'otpauth://totp/OpenVPN?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75'

Streng genommen wird hier durch das Argument -t ANSI ANSI-Art erzeugt, da bei der Ausgabe sogenannte Rahmenzeichen verwendet werden, die im originalen ASCII-Zeichensatz nicht vorkommen. Obwohl mittels -t ASCII eine Ausgabe in echtem ASCII-Art erzeugt werden kann, besteht die Grafik lediglich aus # und Leerzeichen, was deutlich schlechter erkennbar ist und dadurch das Einlesen mit einem Smartphone unnötig erschwert.

Soll stattdessen eine Grafikdatei erzeugt werden, wird mit -t PNG das Ausgabeformat auf PNG gesetzt und mittels -o qr-alice.png der Name der Ausgabedatei angegeben:

$ qrencode -t PNG -o qr-alice.png -s 10 'otpauth://totp/OpenVPN?secret=4LRW4HZQCC52QP7NIEMCIT4FXYOLWI75'

Das Argument -s 10 ist hierbei optional und dient einzig dazu die Größe eines Punkts in der Ausgabedatei von drei auf zehn Pixel zu erhöhen:

Eintrag bearbeiten

Sollte Alice weitere Informationen zu ihrem OTP festhalten wollen, kann sie diese nun selbst von Hand in ihrer App eintragen oder anderweitig festhalten. Auch hierbei muss nicht auf Datensparsamkeit verzichtet werden: um beispielsweise zwei VPN-Einträge auseinanderzuhalten reicht es aus, ihnen verschiedene Issuer, beispielsweise Arbeit und Verein zuzuweisen. Im Falle von andOTP verändert sich hierdurch auch das Icon, welches nun den Anfangsbuchstaben des Herausgebers verwendet.

Fazit

Für die Übermittlung der Shared Secrets an Endbenutzer eignen sich QR-Codes nach wie vor am besten. Bevor man jedoch blind die Gepflogenheiten Anderer kopiert, lohnt es sich, einmal hinter die Kulissen der verwendeten Standards zu schauen und zu überlegen, welche Informationen wirklich übertragen werden müssen und Datensparsamkeit zu praktizieren, wenn eigene QR-Codes erstellt werden.

Durch die Verwendung eines flexiblen Kommandozeilentools wie qrencode ließe sich die Erstellung eigener QR-Codes bei einer größeren Anzahl von Benutzern sogar recht einfach automatisieren.

Unterstützung

Falls Sie Unterstützung bei der Konfiguration oder dem Einsatz von Zwei-Faktor-Authentisierung wünschen, steht Ihnen unser Open Source Support Center gerne zur Verfügung – falls gewünscht auch 24 Stunden am Tag, an 365 Tagen im Jahr.

über den Autor

Jan Bolle

zur Person

Jan arbeitet seit 2020 an Projekten des Support–Teams und der Internen IT, nachdem er bereits sein Praktikum im Rahmen seines Informatikstudiums bei credativ absolvierte und auch seine Bachelorarbeit zum Thema Einmalpasswörter, Zwei–Faktor–Authentisierung und OpenVPN bei credativ schrieb. Bereits zu Schulzeiten interessierte er sich für Freie Software, Netzwerke und Telekommunikation und richtete zusammen mit Mitschülern ein Internetcafé ein, auf dessen Server und Clients Debian GNU/Linux seinen Dienst verrichtete.

Beiträge ansehen