Jump to content
Abschaltung der Forum zum 03.01.2024 ×

Fehlerhafte Implementierung der Spezifikation


Empfohlene Beiträge

Der Authenticator implementiert die Google-Spezifikation (https://github.com/google/google-authenticator/wiki/Key-Uri-Formatnur teilweise, auch werden URL-encodierte Zeichen nicht dekodiert dargestellt, z. B. das @ im Account (falls dieser eine E-Mail-Adresse ist). Die überaus wichtige Information über den Account (Teil des Label-Feldes in der Spezifikation) wird scheinbar nur dann dargestellt, falls der Issuer nur wenige Zeichen hat. Bei mehreren Accounts beim gleichen Issuer, z. B. Github, kann dann nicht zwischen den Accounts unterschieden werden. Die gesamte Darstellung ist, diplomatisch ausgedrückt, noch schwer verbesserungswürdig. 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 16 Stunden schrieb femto:

Der Authenticator implementiert die Google-Spezifikation (https://github.com/google/google-authenticator/wiki/Key-Uri-Formatnur teilweise, auch werden URL-encodierte Zeichen nicht dekodiert dargestellt, z. B. das @ im Account (falls dieser eine E-Mail-Adresse ist). Die überaus wichtige Information über den Account (Teil des Label-Feldes in der Spezifikation) wird scheinbar nur dann dargestellt, falls der Issuer nur wenige Zeichen hat. Bei mehreren Accounts beim gleichen Issuer, z. B. Github, kann dann nicht zwischen den Accounts unterschieden werden. Die gesamte Darstellung ist, diplomatisch ausgedrückt, noch schwer verbesserungswürdig. 

Der REINER SCT Authenticator wurde nach RFC 6238 für eine breite Endkundenmasse entwickelt, dabei können leider nicht immer alle Spezifika und Kombinationen berücksichtigt werden. Wir empfehlen in diesem speziellen Fall im String des QR-Codes den Issuer mit einem Offline-Tool so zu editieren, dass innerhalb der verfügbaren 14 Zeiten des Displays ein eindeutiger Accountname angezeigt werden kann.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ok, mal zwei Beispiele:

  1. Issuer: Google
    Account: foobar@example.com
    OTP-URL: otpauth://totp/foobar%40example.com?secret=abcdef&issuer=Google
    Anzeige des Authenticators: Google:fooba
  2. Issuer: Google
    Account: foobar@example.dev
    OTP-URL. otpauth://totp/foobar%40example.dev?secret=abcdef&issuer=Google
    Anzeige des Authenticators: Google:dev

Warum bitte bekomme ich beim ersten Beispiel den Anfang des Accounts angezeigt und beim zweiten Beispiel das Ende des Accounts? Falls der Authenticator erkannt hat, dass die beiden Einträge bei der simplen Verwendung der ersten n Zeichen identisch dargestellt werden würde, dann sollte dieses Verhalten wenigstens dokumentiert sein, oder habe ich das vielleicht überlesen?

Die erzeugten QR-Codes bzw. OTP-URLs sind korrekt und wurden von mir in verschiedenen Authenticator-Apps mit identischem Ergebnis verifiziert.

Solange der Authenticator solche nicht nachvollziehbaren Ausgaben erzeugt, bleibe ich bei meinem zugegebenerweise harschen Urteil das der Authenticator im Moment nicht brauchbar ist.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich habe jetzt mal versucht das Problem nachzustellen. Das Anzeigeproblem tritt bei mir nicht auf, es wird bei beiden Varianten "Google:fooba" angezeigt. Egal ob ich den QR-Code offline (über Offline-Bibliotheken) oder online (Google Charts) erstelle. Da muss in Deinem QR-Code mehr drin stehen als drinstehen darf. Welche Firmware-Version hast Du auf Deinem Gerät? Es gibt auf dem Markt Geräte mit unterschiedlichen Firmware-Versionen, die erste FW-Version mit 10 Konten und die zweite FW-Version mit 60 Konten. Bei der aktuellen FW-Version sind ein paar Fehler behoben. Das Gerät mit der alten Firmware kann auf die FW-Version mit 60 Konten aktualisiert werden:

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 6.4.2021 um 21:02 schrieb René:

Ich vermute mal, dass es an "dev' liegt, der Authenticator sich daran verschluckt. Was soll "dev" sein?

Ehrlich jetzt?

'.dev' ist genauso wie '.com' eine ofizielle Top-Level-Domain.

Am 6.4.2021 um 22:35 schrieb René:

Ich habe jetzt mal versucht das Problem nachzustellen. Das Anzeigeproblem tritt bei mir nicht auf, es wird bei beiden Varianten "Google:fooba" angezeigt. Egal ob ich den QR-Code offline (über Offline-Bibliotheken) oder online (Google Charts) erstelle. Da muss in Deinem QR-Code mehr drin stehen als drinstehen darf. Welche Firmware-Version hast Du auf Deinem Gerät? Es gibt auf dem Markt Geräte mit unterschiedlichen Firmware-Versionen, die erste FW-Version mit 10 Konten und die zweite FW-Version mit 60 Konten. Bei der aktuellen FW-Version sind ein paar Fehler behoben. Das Gerät mit der alten Firmware kann auf die FW-Version mit 60 Konten aktualisiert werden:

  1. Die QR-Codes habe ich selbstverständlich ebenfalls überprüft, bei allen Tests wurde exakt nur die eigegebene OTP-URL angezeigt.
  2. Das Update des Authenticators war eine meiner ersten Tätigkeiten vor dem ersten Einsatz. Da ich inzwischen mehr als 10 Einträge gespeichert habe, dürfte ich also die zweite FW-Version installiert haben. Aber leider gibt der Authenticator zwar alle möglichen Informationen von sich, aber darunter ist leider nicht die installierte FW-Version.
Link zu diesem Kommentar
Auf anderen Seiten teilen

Hi zusammen,

ich hänge mich mal hier an, da mein Problem in die gleiche Richtung geht. Vorweg hier noch die Infos zu meiner Hardware:

  • ReinerSCT Authenticator mit gerade aktualisierter Firmware V2.06

Mit der alten Firmware (Auslieferungszustand) wurde mir bei den meisten Konten einfach nur "Konto" in der Liste angezeigt, was bei mehr als einem Eintrag natürlich "suboptimal" ist (z. B. beim automatisch generierten QR-Code für meinen Samsung-Account). Welche FW-Version genau im Auslieferungszustand installiert war, kann ich nicht sagen, da - wie von @femto schon angemerkt - die Version ja nicht auf Anhieb für den User ersichtlich ist (vielleicht gibt es einen "Trick"?).

Anschließend habe ich das Update auf V2.06 durchgeführt, in der Hoffnung, dass neben den 60 Accounts vielleicht auch noch weitere Probleme behoben wurden (und dieses unterschiedliche Verhalten bei diversen Accounts sah für mich halt erstmal nach "Bug" aus). Tatsächlich hat sich etwas getan, denn jetzt steht selbst bei den Einträgen, die vorher korrekt angezeigt wurden, noch "Konto:" davor, was die Anzahl der sichtbaren Zeichen stark einschränkt.

Hier wurde auf ein Offline-Tool zum Editieren der Daten/QR-Codes hingewiesen - leider ohne Namen zu nennen. Was könnte man dafür denn nutzen (Windows oder Linux wäre für mich erstmal egal)? Tools zum generieren von QR-Codes gibt es wie Sand am Meer - aber es sollte ja denke ich speziell für 2FA-Codes sein und da bin ich auf Anhieb erstmal nicht fündig geworden. :-(

Aegis-Authenticator zum Editieren
In einem anderen Thread wurde bereits die App "Aegis Authenticator" erwähnt. Auch die habe ich heruntergeladen und bei meinem oben bereits erwähnten Samsung-Account war es dann so, dass ich dort als Name "Samsung-Account" eingegeben habe (das Feld "Herausgeber" war leer) - nach dem Scan des neuen QR-Codes war im ReinerSCT Athenticator dann aber nur besagter "Konto"-Eintrag in der Liste zu sehen. :-(

Ein kleiner Teilerfolg: Füllen des "Herausgeber"-Felds
Jetzt habe ich testweise mal das "Herausgeber"-Feld in Aegis Authenticator mit dem String "Issuer" gefüllt und daraufhin wird auch im ReinerSCT Authenticator in der Konten-Übersicht "Issuer" angezeigt - der eigentliche Konto-Name "Samsung-Account" hingegen ist nicht sichtbar. Dieser taucht nur im "Löschen"-Modus auf. Dort sehe ich im ReinerSCT dann:

Zitat

Löschung
Issuer
Issuer%3ASamsung-Account
C   OK

Generiert die Aegis App jetzt "falsche" QR-Codes, oder wird das Konto-Name Feld vom ReinerSCT nicht korrekt interpretiert? Und welches Tool kann ich verwenden, um selbst mir anhand der OTP-URL anzuschauen, bzw. damit weiter zu "experimentieren"?

Danke im Voraus & Gruß, Erik

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hi René,

Danke für die Info. Deinen Link hatte ich ebenfalls schon in einem älteren Thread gesehen. Von Dir kam dort glaube ich auch der Hinweis auf diese Aegis Authenticator App. Leider habe ich kein Excel, weshalb mir Dein Projekt erstmal nicht weitergeholfen hat.

Ich bin aber trotzdem einen großen Schritt weitergekommen, da das Hauptproblem wohl der fehlende "issuer" Parameter ist. Also zumindest in meinem Fall gab es halt einige Konten, bei denen das nicht gefüllt wurde (ein Beispiel war der vom Handy automatisch generierte Eintrag für den Samsung Account).

Um die Sache zu fixen, habe ich die Google Chrome Erweiterung "Authenticator" verwendet, die ich ohnehin schon länger installiert hatte. Mmit dieser Erweiterung konnte ich sowohl die "issuer"-Felder bei den Einträgen richtig befüllen, die nur "User" gefüllt hatten (und bei denen der reiner SCT Authenticator halt jetzt überall "Konto: " vorangestellt hat), als auch das Problem mit den encodierte Zeichen Zeichen beheben (im "Löschen"-menu wird jetzt nicht mehr "%3A" sondern ":" angezeigt), nachdem ich den von der "Authenticator"-Erweiterung generierten QR-Code in den Reiner SCT Authenticator importiert habe.

Der Weg über das Korrigieren der Daten in der Aegis-App hat bei mir nur bedingt funktioniert, da bei dieser Variante in Reiner SCT Authenticator dann trotzdem noch die URL-encodierten Zeichen für ":" und "@" auf der "Löschen"-Seite nicht korrekt dargestellt werden. Wo genau jetzt die Unterschiede in der OTP-URL sind, habe ich mir heute Abend nicht mehr angeschaut, aber mit dem oben beschriebenen Weg mit der "Authenticator"-Erweiterung als "Zwischenstation" bekomme ich zumindest bei mir jetzt alle relevanten Konten "sauber" im Reiner SCT Authenticator angezeigt.

Gruß, Erik 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das scheint ein Fehler zu sein. Mit "dev" hat das nichs zu tun, der Fehler kommt sobald mehrere Codes ohne Konto-Angabe und dem selben Issuer eingelesen werden, die TLDs sind dabei egal. Ich eskaliere das mal weiter.

 

Umgehen kann man das Problem, indem man den Issuer weglässt und den Kontonamen vor die Emailadresse setzt (getrennt durch Doppelpunkt). So machen es die meisten oder sogar alle Anbieter (Ich kenne das nicht anders, bei all meine 2FA-QR-Codes steht der Kontoname davor, und kein Issuer dabei). Der Issuer ist übrigens optional, da in der Regel immer der Kontoname vor der Emailadresse steht. Wie man das Konto benennt ist auch egal, wichtig ist der korrekte Secret. Aber auch dabei dürfen die Konten nicht den selben Namen haben, sonst kommt es wieder zur Anzeige "dev" und "com".

otpauth://totp/Google-Max:foobar%40example.dev?secret=abcdef

otpauth://totp/Google-Eva:foobar%40example.com?secret=ghijkl

Link zu diesem Kommentar
Auf anderen Seiten teilen

Der "tanJack deluxe" macht es übrigens anders. Der schreibt, wenn der Kontoname fehlt und nur der Issuer angegeben ist, "Google" gefolgt von einer Zahl, je nach Anzahl der Issuer mit dem Namen "Google" ("Google", "Google 2", "Google 3" etc. pp.). Wenn zweimal der selbe Kontoname existiert wird auch dabei ein Zähler genutzt ("Google-Eva", "Google-Eva 2", "Google-Eva 3" etc. pp.). Daher immer einen passenden Kontonamen angeben. Da das Display beim Authenticator jedoch zu klein ist denkt man sich eine "Kurzkennung" aus, die man sich natürlich merken muss.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb René:

So machen es die meisten oder sogar alle Anbieter (Ich kenne das nicht anders, bei all meine 2FA-QR-Codes steht der Kontoname davor, und kein Issuer dabei)

Sorry, aber dem muss ich widersprechen. Alle Anbieter die ich überprüft habe, verwenden ausnahmslos auch den issuer: Amazon, GitHub, Microsoft, um nur ein paar zu nennen. Verständlich, da der issuer eigentlich 'strongly recommended' ist.

Der QR-Code von GitHub selbst ist eigentlich nicht korrekt aufgebaut, da dort der issuer ('authenticator') und der Label Prefix ('Github') nicht übereinstimmen. In diesem Fall sollte eigentlich dem Label Prefix ('Github') Vorzug gegeben werden, der Authenticator verwendet aber wohl den issuer ('authenticator').

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb René:

Mit "dev" hat das nichs zu tun, der Fehler kommt sobald mehrere Codes ohne Konto-Angabe und dem selben Issuer eingelesen werden, die TLDs sind dabei egal.

Ein weiterer Punkt dem ich, zumindestens teilsweise, widersprechen muss:

  1. Issuer 'Google', Label 'foobar@example.com' => 'Google:com'
  2. Issuer 'Google', Label 'foobar@example.dev' => 'Google:dev'
  3. Issuer 'Google', Label 'foobar@example.email' => 'Google:com'

Laut Spezifikation kann der Label alles Mögliche sein z.B. auch nur ein Accountname. Wird in obigem Testfall aber als Label eine E-Mail-Adresse verwendet, so scheint der Authenticator dies durchaus zu erkennen und verwendet dann die TLD zur Unterscheidung der verschiedenen Accounts des gleichen Issuers ('Google').

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Minute schrieb René:

In solchen Fällen habe ich mir angewöhnt, den QR-Code anzupassen, dann kann ich das Konto so benennen wie ich es haben will.

Sorry, aber das ist dann trotzdem nur ein Workaround. Im Prinzip kann der Authenticator ja darstellen, dass es für einen Issuer mehrere Accounts gibt ('Issuer:Account'), nur ist nicht klar nach welchen Regeln er den Account abkürzt um ihn noch auf dem Display anzeigen zu können.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Anderes Problem:
 

  1. Issuer leer, Label 'Amazon:Jane Doe' => 'Amazon' => ok, erstes Amazon-Konto
  2. Issuer leer, Label 'Amazon:John Doe' => 'Amazon:John%' => nicht ok, das '%' ist wohl der Anfang von '%20', also einem URL-encodiertem Leerzeichen.
Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 30.3.2021 um 14:33 schrieb REINER SCT Admin-03:

Der REINER SCT Authenticator wurde nach RFC 6238 für eine breite Endkundenmasse entwickelt, dabei können leider nicht immer alle Spezifika und Kombinationen berücksichtigt werden.

Aber man könnte es mal versuchen. ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 30.3.2021 um 14:33 schrieb REINER SCT Admin-03:

Der REINER SCT Authenticator wurde nach RFC 6238 für eine breite Endkundenmasse entwickelt, dabei können leider nicht immer alle Spezifika und Kombinationen berücksichtigt werden.

Sorry, aber in dem RFC 6238 ist schlicht und einfach nur der TOTP-Algorithmus beschrieben, vom Format der otpauth-URL steht da kein Wort drin. Dieses wurde nämlich von Google erstmals 2010 definiert, wie hier nachzulesen.

Der ständige Verweis auf den RFC 6238 ist IMHO nur eine Art Nebelkerze um von dem Fakt abzulenken, dass die "breite" Endkundenmasse nicht allzu breit sein darf. Ehrlich, wer kauft sich den so ein Teil wie den Authenticator? Die "breite" Masse der Normalbürger sicherlich nicht, das Teil ist eher was für IT-Profis & DevOps mit Zugriff auf eine ganze Menge Accounts mit 2FA.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 54 Minuten schrieb femto:

das Teil ist eher was für IT-Profis & DevOps

Das würde ich nicht sagen. Da der Authenticator autark arbeitet kann er nicht angegriffen werden, ein Pluspunkt in Sachen Sicherheit. Und nur wenige Privatanwender haben bei ein und demselben Anbieter mehrere Konten, die bemerken solche technischen Probleme nicht.

Link zu diesem Kommentar
Auf anderen Seiten teilen

×
×
  • Neu erstellen...

Wichtige Information

Diese Website verwendet Cookies – nähere Informationen dazu und zu Ihren Rechten als Benutzer finden Sie in unserer Datenschutzerklärung am Ende der Seite. Klicken Sie auf „Ich stimme zu“, um Cookies zu akzeptieren und direkt unsere Website besuchen zu können.