2FA in Webapplikation verstehen

[PEASANT KING]

Guten Morgen,

ich habe vielleicht eine simple oder eben auch nicht ganz beantwortbare Frage. Nicht beantwortbar, weil wahrscheinlich geheim, wer weiß.
Ich benötige für Webfrontends eine 2FA. Eigentlich soweit so gut und einfach zu implementieren. Ich möchte allerdings das Ganze Konzept verstehen und vor allem, wie es funktioniert, das der Code, den ich aus meiner Auth App generiert bekomme, mich dazu berechtigt mich sicher anzumelden. Also woher weiß mein Backend, das der Einmalcode der 30 Sekunden meinetwegen gültig ist,
mich dazu berechtigt?
Ich weiß das bei der Erstellung eines Accounts ein Secret Key generiert wird, der in der Datenbank zu meinem Account abgelegt wird.
Diesen kann ich in Form eines QR-Codes in einer Auth App z.B. Google Authenticator oder Microsoft einlesen, worauf hin mir die App einen 6-stellige Zahlenreihe erzeugt. Soweit so gut.
Wieso kennt mein Backend die Zahlenreihe? Hat es was damit zu tun, dass evtl. die Zahlenreihe auch gleichzeitig mit dem Secret Key auf Backendebene generiert wird? Das stelle ich mir übrigens schwierig vor vor allem wenn Zeit eine Rolle spielt, oder wie funktioniert das Konzept?
Mein Ziel wäre es eine eigene 2FA zu implementieren, in der ich nicht auf Google und Co. angewiesen bin.

 

[LasseSamenström]

Grob gesagt, hängt hinter deinem Konto+PW eine mathematische Formel basierend auf der aktuellen Uhrzeit.
Wir haben bspw. einige Kollegen in der Firma die sich nicht in der Sophos VPN einloggen, da der Authenticator auf der App nicht zeitgleich mit der Firewall läuft. Wenn der Kollege nun seinen aktuellen OTP durchgibt, wird wieder gesynct.

 

[nkler]

Im Prinzip wird beim Benutzer und auf dem Server ein Code aus dem Secret generiert. Damit diese sich gleichen, ist die Zeit ein wichtiger Faktor und muss auf beiden Geräten passen.

Hier steht noch mehr dazu. https://datatracker.ietf.org/doc/html/rfc6238

Eine eigene 2FA Implimentierung würde ich mir sparen. Denn der Code ist weder geheim noch von Google und Co abhängig. Dafür ist TOTP allerdings gut vertestet und Besitz keine Kinderkrankheiten.

 

[blablub1212]

Und das wichtigste bei TOTP man kann sich die Codes über unzählige Apps generieren lassen, somit verhindert man auch keine gewohnten Workflows bei den Usern. Wenn eben jemand immer Authy für 2FA nutzt, dann will er es sicher auch auf deiner Seite so tun.

 

[Joshinator]

https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Das ist das Format was du im QR-Code brauchst den der User scannt. Dieses Format können so ziemlich alle TOTP Apps, also nichts was nur Google kann.

Dein Backend führt den selben Code wie die App aus, sowohl Server als auch App kennen die aktuelle Uhrzeit (Unix Time) und das Geheimnis was die App aus dem QR-Code gezogen hat.
Wenn 123456 in der App generiert wird bekommt der Server genau das gleiche Ergebnis zur selben Zeit wenn das gleiche Secret benutzt wurde.


Aber TOTP würde ich nicht selbst bauen, den QR Code zu erstellen damit der User den scannen kann ist in ein paar Minuten gebaut weils nur ne URL ist.

Aber das erstellen vom Secret und verifizieren vom Code gibt man besser an Librarys ab.
Für jede Programmiersprache gibt es da fertige Pakete die dir das alles sauber verpacken und viel wichtiger: getestet haben.

 

[M-X]

Ich würde mir sparen eine eigene 2FA zu implementieren. Da besteht eher die Gefahr das du was falsch machst und eine Sicherheitslücke erzeugt. Setzt auf bewährtes wie TOTP

 

[Zentorno]

Das Prinzip bei der 2FA ist immer ein -personalisiertes- 'Geheimnis'. Also ein Merkmal, welches der Benutzer gar nicht mal unbedingt sieht oder kennen muß (soll er auch gar nicht), welches jedoch dem Server und dem 2.Faktor bekannt sind. Sonst geht's nicht.
Der Server erkennt mit dem 1.Faktor (Login) um wen es sich handelt. Dann prüft er in einem 2.Schritt das persönliche Merkmal, welches nur der Benutzer selber haben kann (bzw. haben sollte) ab.
Dieses persönliche Merkmal ist im Grunde beliebig, es muß nur bei beiden bekannt sein oder sich errechnen lassen.
Wie das Ganze dann in der Praxis aussieht ergibt sich aus diesem Prinzip, z.B.

- TAN Generator mit der Bankkarte: der Benutzer 'identifiziert' sich mit dem Login (1.Faktor). Der Server sucht sich nun das 'Geheimnis', welches diesem Benutzer zugeordnet ist heraus und vergleicht oder errechnet es aus dem Wert, welchen der Benutzer aus dem TAN-Generator erzeugt. Das 'Geheimnis' bzw. der Schlüssel ist hierbei im Chip der Bankkarte abgelegt, im einfachsten Fall eben die IBAN + Kontrollziffern. Das kann gerne so sein, denn dieser Chip ist weder manipulier- noch kopierbar.

- Token-Generator: Der Benutzer loggt sich ein und der Server sucht wieder das 'Geheimnis' dieses Benutzers heraus. Der Benutzer drückt den Knopf an seinem -personalisierten- Token Generator welcher daraufhin eine aus der (quarzUhr-gesteuerten) aktuellen Zeit UND dem persönlichen Geheimnis (im Generator hart-codiert) einen Code generiert. Aus diesem errechnet dann der Server den 2.Faktor und vergleich ihn mit dem im Server hinterlegten 'Geheimnis' dieses Benutzers.

- Mosaikbild (zb. CrontoSign): hier erzeugt der Server aus dem Geheimnis, welches dem Benutzer zugeordnet ist ein Mosaik auf dem Bildschirm welches mit einem personalisierten Lesegerät abfotografiert wird. D.h. dieses Lesegerät muß personalisiert sein, d.h. hart-codiert ein diesem Benutzer zugeordnetes Geheimnis beinhalten.
Der Benutzer tippt diesen Code ein; der Server errechnet das 'Geheimnis' des Benutzers und vergleicht es mit dem beim Server hinterlegten Geheimnis.
<es gibt weiere>

Es ist immer dasselbe Prinzip, nur in anderer 'Darreichung':
Es basiert zwingend auf einem Stück Hardware, welches nur der Benutzer haben kann, dessen 'Geheimnis' aber auch dem Server bekannt sein muß.

Nun kommt's:
da Hardware im Vergleich zu Software Geld kostet und die Diensteanbieter Kosten scheuen wie die Pest drücken sie diese Kosten am liebsten dem Nutzer auf.
'Der soll sich gefälligst ein Schmartfone anschaffen und darauf unsere personalisierte App installieren damit wir uns die Kosten für Token-Generatoren etc. sparen können. Selbst die App hosten wir nicht selbst (spart Kosten) sondern der dumme Kunde soll sie sich im Google Store besorgen.'

Dann muß er einen Account anlegen und seine Daten zur Ausschlachtung hergeben ? Sein Problem.
Akku nicht geladen ? Nicht unser Problem.
Gerät geklaut worden ? Nicht unser Problem.
Kein Netz ? Nicht unser Problem.
Gerät ist durch Viren/Malware/Pegasus kompromittiert ? Nicht unser Problem ...

Daher nutze ich für sowas strikt kein SM.
Bevor Du jedoch selbst eine solche Lösung entwickelst : gibt es massenhaft kommerziell. Z.B. von CrontoSign; auch der Yubi Key könnte eine (populäre) Lösung fürs Web sein.
Kostet halt ... aber Sicherheit UND Komfort UND 'umsonst' schließen sich halt gegenseitig aus