Autor Beitrag
lapadula
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 141
Erhaltene Danke: 7



BeitragVerfasst: Di 19.12.17 12:09 
Hallo, ich beschäftige mich momentan mit der ZFA und verstehe den Sinn dahinter nicht ganz.

Dazu verwende ich die Google Authenticator dll und die dazugehörige App, mit der ich den QR-Code scannen kann.

Den QR-Code generiere ich z. B. folgendermaßen:

ausblenden C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
TwoFactorAuthenticator tfA = new TwoFactorAuthenticator();
            
            var setupCode = tfA.GenerateSetupCode("Titel""EinSecretKey", pictureBoxQR.Width, pictureBoxQR.Height);

            WebClient wc = new WebClient();
            MemoryStream ms = new MemoryStream(wc.DownloadData(setupCode.QrCodeSetupImageUrl));
            this.pictureBoxQR.Image = Image.FromStream(ms);


So wie ich das verstanden habe, hat jeder Benutzer einen eigenen "Secret Key", den könnte ich random generieren und in der Tabelle Benutzer abspeichern.

Wo ich jezt nicht dahintersteige ist, wenn der Angreifer den Benutzernamen und das Passwort kennt, was sollte ihn davon abhalten den QR code zu scannen und die 6 Ziffern einzugeben?
FinnO
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1325
Erhaltene Danke: 117

Mac OSX
TypeScript (Webstorm), Kotlin, Clojure (IDEA)
BeitragVerfasst: Di 19.12.17 13:59 
Naja, das Scannen liefert halt nur die richtigen Ziffern, wenn du dich im Google Authenticator schon mit dem korrekten Google Account angemeldet hast.

Der Angreifer muss also neben Benutzername und Passwort auch noch das Mobiltelefon, bzw. den Google Account des Angriffsopfers übernehmen. Daher der Name Two-Factor ;-)
lapadula Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 141
Erhaltene Danke: 7



BeitragVerfasst: Di 19.12.17 14:08 
Im Google Authenticator muss man sich nicht einloggen. Es macht mehr Sinn, wenn der Benutzer den QR Code nur einmalig einscannt.
Damit wird alle 30 Sekunken ein neuer 6-stelliger Code in der App generiert und diesen muss der Benutzer zusätzlich zu seinem Benutzernamen und Passwort eingeben.

Wenn man den QR code jedes mal einscannt, dann ist der Code ja immer gülitg. Der Angreifer kann sich die App natürlich auch runterladen und den QR-Code scannen und die 6 Ziffern eingeben. Hoffe ich liege da jetzt nicht daneben.

Für diesen Beitrag haben gedankt: FinnO
FinnO
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1325
Erhaltene Danke: 117

Mac OSX
TypeScript (Webstorm), Kotlin, Clojure (IDEA)
BeitragVerfasst: Di 19.12.17 14:18 
Okay, dann klingt das Vorgehen was du beschreibst nach dem Vorgehen, welches man bei der ersten Registrierung des Nutzers bzw. bei der ersten Aktivierung der Two-Factor Authentication (TFA) nutzt.

Ich finde jetzt so spontan keine Dokumentation in der ich das nachlesen kann, aber ich rate mal weiter ;-)

Beim ersten Initialisieren der TFA, sei es bei der Registrierung oder bei der späteren Aktivierung in den Nutzereinstellungen, wird einmalig der QR Code als Seed für die Google Authenticator App genutzt. Danach zeigt diese nach dem üblichen Vorgehen in regelmäßigen Zeitanständen einen Passcode an, welcher bei zukünftigen Transaktionen zur TFA genutzt wird.

Genau so, wie der QR-Code nur einmalig angezeigt wird, wird auch das nutzerspezifische Secret nur einmal generiert. Klar, bei der ersten Einrichtung der TFA erhöht diese die Sicherheit noch nicht. Aber im Idealfall - also bei gleichzeitiger Registrierung des Nutzers und Aktivierung der TFA - gibt es ja eh' noch nichts zu schützen.

Für diesen Beitrag haben gedankt: lapadula
lapadula Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 141
Erhaltene Danke: 7



BeitragVerfasst: Di 19.12.17 15:02 
Gut, also alles nur eine einmalige Sache mit dem QR-Code und dem SecretKey.

Eine Frage hätte ich noch. Nun werden nicht alle Benutzer ein Smartphone haben um den QR Code zu scannen. Meine Idee ist, den 6-stelligen Code alternativ an die hinterlegte E-mail Adresse zu verschicken. Das reisst wieder Lücken in das System aber was anderes fällt mir da auch nicht ein. Und den SecretKey kann ich in der Datenbank auch nur im Klartext speichern. Es kommt mir alles unsicher vor und ich frage mich ob TFA überhaupt Sinnvoll ist.


github.com/BrandonPo.../GoogleAuthenticator
FinnO
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1325
Erhaltene Danke: 117

Mac OSX
TypeScript (Webstorm), Kotlin, Clojure (IDEA)
BeitragVerfasst: Di 19.12.17 16:55 
Moin,

naja, ein e-Mail-Konto ist natürlich auch ein zweiter Faktor.

Üblicherweise nutzt man aber sonst SMS oder ein physikalisches Gerät als zweiten Faktor. Natürlich sind letztere gehackt und SMS unnötig langsam, instabil und teuer, aber was tut man nicht alles.

Ich bin mir noch nicht ganz sicher, ob dir klar ist was der exakte Anwendungszweck von TFA ist.

TFA ist fügt zum normalen Loginprozess eine zusätzliche Authentifzierungsmethode hinzu. Das Passwort ist etwas, "das man weiß". Dazu kommt dann oft etwas "das man hat", z.B. ein Smartphone mit Google Authenticator, oder etwas "das man ist", z.B. biometrische Daten wie Fingerabdruck oder Iris-Scans. Weitere mögliche Faktoren sind z.B.

* RSA-IDs
* Yubikeys
* SSH oder GPG Keys

Man muss nicht für jede Nutzeraktion an jedem Gerät TFA verwenden. Oft kann TFA auf einem bestimmten Gerät (widerrufbar) deaktiviert werden - bei Facebook nennt sich das "diesem Computer vertrauen". Trotzdem kann man für manche, besonders kritische Aktionen - z.B. Ändern des Passworts, Hinzufügen eines SSH Public-Keys, ... - immer auf erneute Authentifizierung mit zwei Authentifizierungsfaktoren bestehen.

Für diesen Beitrag haben gedankt: lapadula