Erhöht 2FA wirklich die Sicherheit, oder ist es nur eher nervig?

[kachiri]

Es gibt viele eingeführte Schutzmaßnahmen im Internet, die nerven. 2FA gehört für mich definitiv nicht dazu - und persönlich sehe ich das Thema 2FA eher aus Sicht des unvorsichtigen Nutzers. Von denen gibt es viel mehr. Und dort ist es definitiv eine Steigerung der Sicherheit um ein Vielfaches...
Für den, der sich sicher ist, dass er bereits ein sehr schwieriges und für jeden Dienst individuelles Passwort in Kombination mit einem (dann aber hoffentlich per 2FA) gesicherten Passwortmanager nutzt, ist 2FA vielleicht eher ein "Ärgernis". Aber die Mehrzahl der Menschen nutzt Passwörter wie "passwort" oder "12345..."
Ich kann mich sogar noch an Zeiten erinnern, wo man bei Webseiten das Admin-Passwort des CMS in den (ungeschützten) Konfigdateien im Klartext hinterlegt hat und das "Beispielpasswort" nie geändert wurde. Da kam man auf etliche Seiten mit "demo" oder "admin" ins CMS....

 

[TomH22]

Bestimmt mache ich irgendwo einen Denkfehler - aber wo?

Nein, Du machst nicht direkt einen Denkfehler, wenn Deine Vorraussetzungen zutreffen, dann ist auch ein normales Passwort sehr sicher.

Aber die Vorraussetzungen treffen im realen Leben eben nicht immer zu.

Der größte Risikofaktor bei vielen Internetdiensten ist die „ich habe mein Passwort vergessen“ Funktion. Oft wird das Passwort ja ohne weitere Prüfung über einen E-Mail Rücksetzlink neu gesetzt. Die E-Mail Adresse ist also der einzige „Proof-of-ownership“. Da nun aber klassische IMAP Accounts nur über Passwörter, die obendrein im EMail Client gespeichert sind, abgesichert sind, ist dass das schwache Glied in der Kette.

Deswegen setzen sich zusätzliche Prüfungen, wie etwa SMS, vertrauenswürdige Geräte, etc. als zusätzlicher Schutz bei Passwort Rücksetzungen oder neuen, ungewöhnlichen Anmeldungen immer mehr durch. D.h. selbst wenn man keine 2FA eingerichtet hat, gibt es „zwangsweise“ 2FA in bestimmten Situationen. Genau diese führt aber auch gerne mal zu Problemen bei nachlässigen Anwendern, z.B. ungültige Telefonnummern für SMS.

Ein Fallstrick von 2FA ist natürlich der Verlust des zweiten Faktors. Man sollte sich unbedingt bei der Einrichtung von 2FA über das jeweilige Recovery Verfahren schlau machen.

 

[Krik]

Mal angenommen, ich habe ein sicheres/starkes Passwort gewählt, und bin mir sicher, dass mein Computer oder Smartphone nicht kompromittiert ist, und der Benutzer und das Passwort wird beim Login immer verschlüsselt übertragen

Wie @Piktogramm schon schrieb, kannst du nicht einfach die Szenarien ausblenden, für die die 2Faktor-Authentifizierung entwickelt wurde:

• Egal wie stark ein Passwort ist, es kann trotzdem entwendet werden. Bei 2FA muss man zwei "Passwörter" entwenden.
• Wenn ein Computer kompromittiert wird, ist es relativ unwahrscheinlich, dass der zweite Faktor auch kompromittiert wurde. Mein TAN-Generator z. B. hängt nicht am Netz und kann daher auch nicht durch einen Trojaner oder ähnliches beeinträchtigt werden.
• Eine verschlüsselte Verbindung ist nur so sicher, wie die Endpunkte der Verbindung es sind, womit man wieder bei den kompromittierten Computern und Smartphones landet.

2FA bietet auch dann noch Sicherheit, wenn einer der beiden Faktoren kompromittiert wurde.

Es ist zwar denkbar, dass der zweite Faktor auch geknackt wird, aber die Wahrscheinlichkeit ist extrem gering.
Angenommen, man braucht bspw. 1.000 Versuche, einen Faktor zu knacken. Dann
braucht man 1.000² = 1.000.000 Versuche, um beide Faktoren gleichzeitig zu knacken. Aber auch nur dann, wenn der zweite Faktor vom Netz aus erreicht werden kann. Ist der zweite Faktor offline, bist du quasi unknackbar - es sei denn, man bricht bei dir ein.

 

[Looniversity]

Der größte Risikofaktor bei vielen Internetdiensten ist die „ich habe mein Passwort vergessen“ Funktion.

Ja, das ist ein Riesenproblem. Auch noch aus anderen Gründen. Wenn ein Gerät oder Zugang futsch ist, hält 2FA nämlich nicht nur andere, sondern auch sich selbst effektiv draußen.
Dazu habe ich hier mal was "aus dem Leben" geschrieben. Mit Passkeys kann man leichter Backups auf anderen Geräten machen.

 

[kachiri]

Wenn ein Gerät oder Zugang futsch ist, hält 2FA nämlich nicht nur andere, sondern auch sich selbst effektiv draußen.

Schuldig ist hier aber nicht 2FA, sondern im Endeffekt der Nutzer, der sich selbst aussperrt, weil er 2FA nicht ernst nimmt oder dem gar keine Beachtung schenkt. Da werden dann in Pflichtfelder wie Mobilnummer oder alternative E-Mail-Adresse dann irgendein Schmarn eingetragen.
Selten ist es auch die Tatsache, dass die Leute ihre Mobilnummer und E-Mails wie Unterhosen wechseln und vergessen diese dann auch entsprechend neu bei den diversen Diensten zu hinterlegen, die sie nutzen.

Das kann man aber aus meiner Sicht nicht 2FA zuschreiben. Genauso wenig wie die Tatsache des "Passwort vergessen".

 

[Looniversity]

Schuldig ist hier aber nicht 2FA, sondern im Endeffekt der Nutzer, der sich selbst aussperrt, weil er 2FA nicht ernst nimmt oder dem gar keine Beachtung schenkt. Da werden dann in Pflichtfelder wie Mobilnummer oder alternative E-Mail-Adresse dann irgendein Schmarn eingetragen.

Da mag ich widersprechen; die meisten Dienste lassen nur einen 2FA-Weg gleichzeitig zu. Wenn der weg ist helfen auch die echten Daten nichts. Google ist da deutlich besser aufgestellt, aber wenn denen etwas komisch vorkommt (wie bei mir mein Login von der anderen Seite der Erde) rettet dich das nicht, weil der Dienst dicht macht bis dein Login wieder ins übliche Muster passt.

Aber ja, wer eine fake-Nummer oder eine erfundene E-Mail als 2FA oder Recovery angibt, hat sich eventuelle Probleme selbst zu verdanken.

 

[CyborgBeta]

Nein. Hashes und salt ist nicht gegen brute force.
Das ist da um Passwörter nicht im klartext zu speichern und wenn dann doch mal was weg kommt gegen rainbow tables etwas immuner zu sein

Dann versuche bitte, diesen Passwort-Hash zu knacken:

Digest: $argon2id$v=19$m=4194304,t=4,p=4$NrJJJUx187zv3hCV5PSE8Q$c/LLqeD+GZbBH646m8nkNT5dwnbLSdiLzDlQYFovwBA

Tipps:

• Variante: argon2id
• Iterationen: 4
• Parallelism: 4
• Memory: 4gb
• Salt size: 16
• Key size: 32

Zeit, um es zu erstellen, auf einem schnellen Computer: ca. 4,5 Sekunden.

---

Seite 2 hier lese ich mir später auch noch durch, ich muss aber erst weg ...

 

[madmax2010]

Das ist doch an der Stelle nicht relevant und nicht der abzudeckende vektor.

Hashing passiert heutzutage zumeist auf dem Server, weil man auf dem Weg weniger Angriffsfläche hat.
Wenn er unsauberes session rate limitieren hat nervst du bei den Einstellungen halt den Betreiber mit den Einstellungen, aber eben deshalb helfen hash und salt nicht gegen bruteforce.

https://en.wikipedia.org/wiki/Password_cracking

A common approach (brute-force attack) is to repeatedly try guesses for the password and to check them against an available cryptographic hash of the password

The use of salt, a random value unique to each password that is incorporated in the hashing, prevents multiple hashes from being attacked simultaneously and also prevents the creation of pre-computed dictionaries such as rainbow tables.

Was du sagst ist nicht falsch und es ist auch korrekt und notwendig, aber es ist nichthinreichend

 

[CyborgBeta]

nervst du bei den Einstellungen halt den Betreiber mit den Einstellungen

genau deshalb habe ich real auch niedrigere Einstellungen gewählt ... das war jetzt nur zum Test.

Aber praktisch kann dieser Hash nicht gebruteforced werden, wenn man ein starkes Passwort gewählt hat.

session rate limitieren

Habe ich auch drin, man hat höchstens 10 Versuche, danach greift iptables mit reject.

Also ja, es existieren Angriffsflächen, wenn das Verfahren nicht gut implementiert wurde, aber das Verfahren an sich ist nicht unsicher.

 

[Piktogramm]

Dann versuche bitte, diesen Passwort-Hash zu knacken:
[...]

Das ist wieder ein "Aber schau doch her, ICH habs drauf" in völliger Ignoranz der restlichen Welt.

Als Betreiber eines Onlineservices wird Niemand diese Parameter mit Argon2 wählen. Jeder Loginversuch würde praktisch bedeuten, dass der zuständige Server 4Threads, 4GB Ram über Sekunden ausgelastet hat. Da die dicken Serverprozessoren meist auch geringere Taktfrequenzen sehen als dein Benchmarkmaster9000, wären die Threads auch eher 8..16s aktiv.
Ein solches Login wäre also ein super Einladung für einen DDOS, mit unter 50Requests/s könnte man bei diesen Hashingparametern alle Loginserver abschießen, die nicht in der Größenordnung Alphabet, Facebook, Amazon liegen. Jeder popeliger Onlineshop brauchte fürs Login ein 2Sockel Epyc.
TLDR: Total unrealistischer Unfug.


Die Einstellungen die du da zeigst sind, sind allenfalls sinnvoll für Passwortmanager auf einem 1Client-System. Für den Fall, dass da die verschlüsselte Datei des PW-Storages in die Hände an Dritte kommt, sind diese Einstellungen durchaus geeignet um Angreifer allerhand Aufwand abzuverlangen, sodass du mindestens Tage, realistisch durchaus >=1Jahr Zeit hast bei allen Diensten die Passwörter zu ändern.
Das wäre dann auch eine halbwegs sinnvolle Begründung fürs jährliche Wechseln von Passwörtern, wenn man seinen PW-Storage aus Gründen in der Welt verteilt. Aber es ist eben auch eine sinnvolle Anwendung für 2FA, da der Aufwand für Dritte dadurch nochmals deutlich gesteigert wird.

 

[CyborgBeta]

Das ist wieder ein "Aber schau doch her, ICH habs drauf" in völliger Ignoranz der restlichen Welt.
...
TLDR: Total unrealistischer Unfug.

tl;dr: Wieder mal nur die Hälfte gelesen und nicht verstanden. Der Hash ist auch mit niedrigeren Einstellungen sicher.

 

[TomH22]

Dazu habe ich hier mal was "aus dem Leben" geschrieben.

Habe den Beitrag nur überflogen - TL;DR
Die Anti-Fraud Mechaninsmen von z.B. Google, Apple, Microsoft können natürlich ganz gut nach hinten losgehen, vor allem für so Fälle wie im Urlaub Handy verloren.
Die hätten aber auch zugeschlagen, wenn Du nicht explizit 2FA eingerichtet hättest.

Hier helfen nur aktive Gegenmassnahmen:

• Ich fahre niemals mit nur einem Gerät in den Urlaub, mindestens mein iPhone und mein iPad sind immer dabei - und die fungieren beide als "vertrauenswürdige Geräte". Ich achte darauf, beide Geräte, wenn möglich, getrennt zu halten. Also z.B. iPad im Handgepäck, iPhone am Körper.
• Meine Frau und ich sind gegenseitig bei Apple als Wiederherstellungskontakt eingetragen.
• Von meinen TOTP Codes habe ich ein Backup des Startwertes in der Cloud - ja das schwächt die Sicherheit von den TOTP Codes, das ist halt ein Trade Off.
• Recovery Codes sind auf meinem Synology NAS auf einem verschlüsselten Volume gespeichert, dass nur bei Bedarf eingebunden wird. Auf das NAS kann ich per Wireguard zugreifen. Solange also noch eines unserer Geräte vorhanden ist, würde ich darüber an die Codes kommen.

Der Hash ist auch mit niedrigeren Einstellungen sicher.

Trotzdem hat die Diskussion um Paswort Hashes mit 2FA nur am Rande zu tun. 2FA ist in erster Line dafür gedacht als Gegenmassnahme gegen menschliche Schwächen beim Handling von Passwörtern zu wirken.

Insofern liegst Du richtig, dass der Sicherheitsgewinn durch 2FA gering ist, wenn ein starkes und einmaliges Passwort verwendet wird. Derselben Annahme folgen App-Kennwörter, die als Workaround für nicht 2FA taugliche Anmeldeprozesse an 2FA gesicherte Konten verwendet werden.

 

[Piktogramm]

tl;dr: Wieder mal nur die Hälfte gelesen und nicht verstanden. Der Hash ist auch mit niedrigeren Einstellungen sicher.

Du schreibst nichts von niedrigeren Einstellungen. Du beschreibst genau(!) einen Parametersatz. Worauf ich mich beziehe, da diese Parameter so zwar für Einzelanwendungen auf einem System gehen, aber schlicht unbrauchbar sind für Systeme die exponiert sind und mehr als einen Request gleichzeitig bearbeiten müssen. Das ist dein Post:

Dann versuche bitte, diesen Passwort-Hash zu knacken:

Digest: $argon2id$v=19$m=4194304,t=4,p=4$NrJJJUx187zv3hCV5PSE8Q$c/LLqeD+GZbBH646m8nkNT5dwnbLSdiLzDlQYFovwBA

Tipps:

• Variante: argon2id
• Iterationen: 4
• Parallelism: 4
• Memory: 4gb
• Salt size: 16
• Key size: 32

Zeit, um es zu erstellen, auf einem schnellen Computer: ca. 4,5 Sekunden.

[...]

Mit Einstellungen, die realistischer sind für exponierte Systeme (z.B. Loginserver[2]), rutscht das Ganze in Bereiche, wo ein Angreifer BruteForce sinnvoll auf die häufigsten 10.000 Passwörter + ein..zweifache Permutation fahren kann[1]. Damit ist der Ansatz so nicht gegen typisch(!!) Fehlnutzung durch Nutzer·innen gewappnet. Hier hilft 2FA, Passkeys und/oder als Minimum gescheite Passwortregeln.


[1]Bedingung ist, Angreifer kommt an den Hash und/oder der Loginserver ist ohne Ratelimit und recht mächtig.

[2] Vergleich, die Empfehlung von Owasp für exponierte Authentifizierung: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
Argon2id: 19MiB, 2 Iterationen, 1Thread
Das ist WEIT entfernt von deiner Annahme und wenn die minimalen Anforderungen von OWASP mal eingehalten werden würden, wäre die Welt deutlich weiter. Oder andersherum, du kannst davon ausgehen, dass die Komplexität vom Hashing bei vielen Anbietern deutlich geringer ist

Bestimmt mache ich irgendwo einen Denkfehler - aber wo?

Dein Denkfehler ist die Ignoranz gegenüber typischer Fehlbedienung durch Nutzende, Admins, dir selbst und dem Ignorieren wirtschaftlicher Rahmenbedingungen.

Naja und wenn es um einer Authentifizierung gegenüber Dritter geht, dann hast du als Nutzer in der Regel so oder so keinen Einfluss auf den Hashingalgorithmus und dessen Parameter. Ein 2FA-Verfahren liefert je nach Implementierung (sehr kurz: Fido2 Token gut, SMS-Tan schlecht), tendenziell ein deutlich besseres Schutzniveau.

 

[CyborgBeta]

@Piktogramm Bin kein Fan von Security by obscurity, deshalb sind hier meine realen Server-Einstellungen:

    password:
      algorithm: 'argon2'
      argon2:
        variant: 'argon2id'
        iterations: 3
        memory: 65536
        parallelism: 4
        key_length: 32
        salt_length: 16

Mit 64 MiB Speicher läuft der Hash-Algorithmus deutlich schneller, und zudem sind die Versuche auf 10 begrenzt. Für meine Zwecke ist dies absolut ausreichend (vermutlich könnte man nun mit einem Dreisatz die Laufzeit herleiten, wenn 4 GiB 4,5 s brauchten) ... und diese Einstellungen werden auch offiziell so empfohlen.

Ok, aber ihr habt recht, Passwort-Hashes haben nur noch bedingt mit dem eigentlichen Thema (2FA) zu tun, deshalb würde ich es einfach erst mal dabei belassen.

---

E-Mail-App-Passwörter untergraben, wie es im Eingasposting steht, leider die Sicherheit von 2FA, das stimmt auch.

 

[Piktogramm]

und diese Einstellungen werden auch offiziell so empfohlen.

Für welchen Anwendungsfall und von Wem (lies: Quelle?)

Und wenn du von Server schreibst, ist das Ding öffentlich exponiert? Denn wenn ja, mit 10 aktiven Loginversuchen brauchen solche Einstellungen ~640MiB, 40Threads. Für den Fall, dass der Server überhaupt 40Threads bereitstellen kann für etwa 4..10s. Das ist ein DDOS-Opfer erster Güte, selbst mit Ratelimits.

Und die Themen gehören zusammen, du oder andere Anbieter haben begrenze Ressourcen, die Angreifer tendenziell immer mehr und die Annahme sollte auch sein, dass Angreifer immer schlauer sind. Gescheites 2FA erhöht die Komplexität für Angreifer um Größenordnungen, bei minimalen Ressourcenbedarf für Anwender und Anbieter. Zudem fängt gescheites FA weitere Fehlanwendungen durch Nutzer·innen ab.

 

[CyborgBeta]

Quelle?

https://www.authelia.com/reference/guides/passwords/#recommended-parameters-sha2-crypt

Ergänzung (18. Mai 2025)

Und wenn du von Server schreibst, ist das Ding öffentlich exponiert? Denn wenn ja, mit 10 aktiven Loginversuchen brauchen solche Einstellungen ~640MiB, 40Threads.

Das ist bei 64 GB RAM wohl vernachlässigbar.

 

[Piktogramm]

Ok ich muss einen Fehler eingestehen. Danke fürs Verlinken der Quelle @CyborgBeta. Die Genannten Parameter sind auf modernen Prozessoren ja wirklich ein Witz und laufen auf Zen2 in 0,15s (APU), ~0,25s (Epyc) durch und auf AlderLake-N in <0,3s.
Epyc 7702P:

echo foobar | argon2 "deadbeef" -id -t 3 -k 65536 -p 4 -l 32
Type:           Argon2id
Iterations:     3
Memory:         65536 KiB
Parallelism:    4
Hash:           81c0ccf599ec5c7634653abe9d291b3f3c2ec88e115459b97e9637bc70f936b5
Encoded:        $argon2id$v=19$m=65536,t=3,p=4$ZGVhZGJlZWY$gcDM9ZnsXHY0ZTq+nSkbPzwuyI4RVFm5fpY3vHD5NrU
0.252 seconds
Verification ok

Das sind so Bereiche, wo DDOS vom Loginserver weniger ein Problem ist, als zukünftig, dass BruteForce zum Problem wird. Mimimi alter Mann findet Entwicklung doof. -.-

Wäre aber wieder ein Grund für 2FA.

 

[madmax2010]

modernen Prozessoren ja wirklich ein Witz und laufen auf Zen2 in 0,15s (APU), ~0,25s (Epyc) durch und auf AlderLake-N in <0,3s.

da geht noch was

model : 68
model name : AMD Ryzen 5 9600X 6-Core Processor
enoch@pve-blackwell07:~# echo foobar | argon2 "deadbeef" -id -t 3 -k 65536 -p 4 -l 32
Type: Argon2id
Iterations: 3
Memory: 65536 KiB
Parallelism: 4
Hash: 81c0ccf599ec5c7634653abe9d291b3f3c2ec88e115459b97e9637bc70f936b5
Encoded: $argon2id$v=19$m=65536,t=3,p=4$ZGVhZGJlZWY$gcDM9ZnsXHY0ZTq+nSkbPzwuyI4RVFm5fpY3vHD5NrU
0.062 seconds
Verification ok

 

[CyborgBeta]

https://www.authelia.com/reference/guides/passwords/#recommended-parameters-sha2-crypt

Sorry, man muss einen Absatz weiter hoch schauen ...

@Piktogramm Ja, die Hashing time ist nicht so das Problem.

 

[Aktaion]

Für mich eine Glaubensfrage wie TPM und Secureboot. Wer es will soll es tun.