Nachdem ich sicherheitstechnisch in den letzten Jahren auf lange, kryptische Passwörter in Zusammenarbeit mit Enpass gesetzt habe, möchte ich nun einige Logins auf 2FA umstellen.
Welche Authentifizierungs-Apps sollte ich verwenden?

Google Authenticator. Aber ist das sinnvoll und zielführend bei sicherheitskritischen Apps ausgerechnet auf die Datenkrake Google zu setzen? Und das noch vor dem Hintergrund, das Google schon etliche gute Tools einfach hat sterben lassen?

‎Microsoft Authenticator. Hüstel. Wirklich?

Synology Secure SignIn. Würde passen, da ich eh eine Synology besitze und auch dort 2FA aktivieren möchte. Aber: Taiwanesische (= chinesische) Software.

Oder sehe ich das alles zu eng? Was setzt ihr ein bzw. was könnte ihr (nicht) empfehlen?

Huba

Ich kann die von Proton aus der Schweiz empfehlen

Sollte das Enpass nicht selbst können? https://support.enpass.io/app/item/generating_one_time_code_in_enpass.htm|

Ich verwende einen anderen Passwortmanager, habe aber dort auch die Verwaltung der 2FA drinnen und keine eigene Authenticator App mehr.

OTP Auth
Infos dazu

2FAS
Super schlanke App ohne Werbung oder nerviges rundrum
Macht seit Jahren genau das, was sie soll👌🏻

Super Tipp! Proton benutze ich jetzt auch.

In der Firma benutzen wir: Secure SignIn

Noch zu Synology.

Taiwan ist die Republik China und nicht die Volksrepublik China. Da würde ich mir keine Gedanken machen. Außer die VC startet morgen tatsächlich eine Invasion und möchte Taiwan annektieren. Die Chips im iPhone/Mac sind auch von der Insel - TSMC.

Ich sehe bei Taiwan und China durchaus einen Unterschied.

Die ist top und synct via iCloud auf iPhone, iPad und Mac.

Da ich sowieso 1Password benutze, bekomme ich auch die 2FA daraus.

habe Step Two verwendet und jetzt neuerdings Apples Passwörter weil man es da gleich drin hat

Einfach Enpass weiter nutzen. Kann doch 2FA inklusive auch der neuen „acces Keys“.
Und Sync über deine Syno.

Oder, wenn es Cloud Sync sein darf, den Schlüsselbund des Systems.

Ich nutze Authy von Twilio und bin damit sehr zufrieden.

Authy habe ich bis vor ca. einem Jahr auch zufrieden genutzt. Es gab dann wohl verschiedene Hacking-Angriffe.
Ich habe dann auf 2FAS umgestellt. Frei und Open-Source-Software.

2FAS 👍
Sollte Enpass in diesem Fall kompromittiert werden, ist der zweite Faktor nutzlos.
Das wäre dann höchstens 1,5FA

Apple Passwörter kann das wohl jetzt auch:

Hüstel. Wirklich?

Geschichte nach 5 min komplett abgewählt und diesbezüglich auch sonst in einer Blase auf dem Mars gelebt?

Dann ist noch viel eher Apple Microsoft.

Hach Gott ja. Ich wollte jetzt keine geopolitische Diskussion vom Zaun brechen. Natürlich ist Taiwan eine unabhängige Inseldemokratie, aber die Frage ist nicht ob, sondern wann China dagegen etwas unternimmt. Wenn TMSC seine Fertigung nicht strategisch bewusst in der Nähe von wichtiger militärischer und wirtschaftlicher Infrastruktur platziert hätte, wäre es wohl schon längst so weit gewesen. Selbst China kann es nicht riskieren, auf diese Fabriken zu verzichten.
Ich habe selbst Freunde und Bekannte, die in Taiwan leben und halte mich für recht gut informiert. Ich wollte nur diese Fragestellung nach 2FA nicht unnötig aufblähen und wortreich darlegen, warum ich langfristig nicht unbedingt auf taiwanesische Produkte setzen möchte. Aber das konntet ihr natürlich nicht wissen — darum danke, dass ihr so gut mitlest und aufpasst.

Danke für die vielen Tips! Da gibt es für mich viel zum Ausprobieren.

Kannst einfach die Passwörter-App von Apple verwenden – sowohl auf dem Mac als auch unter iOS.

Die Frage ist doch, ob Du Huba das Risiko für realistisch hältst, dass jemand Zugriff auf die Passwörter in Enpass erhält.
Falls nein, dann ist es komfortabler die TOTP in Enpass zu verwalten. In vielen Passwortmanager ist es so, dass nach dem Kopieren und Einfügen des Passworts automatisch der TOTP in den Zwischenspeicher kopiert wird. Man muss also nur 2x cmd + V drücken. Das ist viel praktischer als eine zweite App zu öffnen.
Die TOTP sind alphanumerische Schlüssel, auf deren Basis ein 6-stelliger Code berechnet wird (das geht sogar mit einem eigenen lokalen 15-zeiligen Shell-Skript). Das besondere an diesem Schlüssel ist, dass er nie geteilt wird. Die Schlüssel sind aber wie Passwörter leicht übertragbar auf einen anderen Passwortmanager, weshalb es gar nicht so bedeutend ist, ob ein Dienst später mal eingestellt wird. Der Schlüssel sollte aber anzeigbar sein.

Hallo,

wenn ich das richtig verstehe, geht es Dir nur um eine App für die »Einmalcode«?
Ich teile es auf in:
MS Authenticator => berufliche Schlüssel und
UniFi Verify => privates Schlüssel.

Damit hast Du eine zusätzliche Trennung. Dennoch – nur überflogen – kann ich die Einwände hinsichtlich chinesisch/taiwanesich oder sonstiger Sicherheitsbedenken nicht so ganz nachvollziehen. Es geht um temporäre Zahlencodes und nicht um die Speicherung der Passwörter, oder ?? Ich würde NIE beides in einer App nutzen !! Damit wären ja das Passwort UND die Freischaltung zusammen verfügbar.

Ich persönlich nutze keinerlei App zum Speichern von wesentlichen Passwörtern. DAS wäre mir viel zu unsicher ( ein unzufriedener oder eingeschleuster Programmierer und alles ist kopiert… kleines Hollywood Szenario… ). Lediglich Apples Passwords für Webseiten, die »unwichtig« sind, also nur Newsletter u.ä., bei denen nichts relevantes hinterlegt ist. Der Rest wird von Hand eingegeben, jedes Mal… Nervig? JA. Sicher? Schon eher.

So, hoffe, ich hab's richtig verstanden und damit einen relevanten Teil beigetragen.
Schon mal einen guten Start in die Woche !! C.

Dein Authenticator ist auch nur ein Passwortmanager. Nimm ein "Passwort" von deiner Papierliste, z.B. AAAATHPVAAAA7XMU (Anzahl Vielfaches von 8 ) und führe das Skript aus:
Du erhältst den gleichen 6-stelligen Code wie deine Authenticator-App.
Das ist der Kern so einer App als Skript (und funktioniert auch):

Ja, aber die Frage ist ja, ob es auch andersherum geht ???
Außerdem, so habe ich es zumindest verstanden – hoffentlich – wird die Berechnung aus dem Password heraus ja nicht in der 2FA-App erzeugt, sondern nur der fertige Startwert der Berechnung wird ( meistens ) via QR-Code eingelesen. Ergo weiß die 2FA-App ja nicht, wie das Passwort lautet.

Greetings, C.

Ich hatte damals mit Google Authenticator angefangen (stand-alone, kein Sync) und migriere und empfehle im Bekanntenkreis mittlerweile den bereits genannten Proton Authenticator , u.a. auch im Zuge eines "De-Googleings".

Bietet für iOS, Android, MacOS, Linux und Windows Clients. Kann mit Passwort und/oder biometrischer Sperre (auf iOS z.B.) zusätzlich geschützt werden. Da man aber in der Regel ein Phone Lock Code und/oder die vorhandene biometrische Sperre sowieso bereits im Einsatz hat, hab ich für mich entschieden auf dem iPhone keinen zusätzlichen Schutz drüber zu legen, da es komfortabler ist den Authenticator schnell(er) aufzurufen und nicht nochmal eine weitere Hürde überwinden zu müssen.

Wichtig ist, dass ein Authenticator offline genutzt werden kann und kein Account Zwang herrscht sowie auch keinerlei Art von Cloud-Sync mandatorisch ist. Von daher würden für mich hier einige genannten Lösungen schon durchfallen.

Ferner ist Proton Authenticator Open Source (GPL) .

Als weitere, ebenfalls im Einsatz befindliche Lösung, ist KeepassXC , mit dem ebenfalls 2FA verwaltet werden kann. Bekannterweise ebenfalls (ggf. "besseres Open Source" als Proton?) Open Source bzw. DIE FLOSS-Lösung, wenn es um Password Manager (und in diesem Kontext "2FA-Manager") geht.

Zu empfehlen ist einen separate .kdbx-Vault anzulegen für 2FA Codes, so dass diese prinzipiell nie im selben Vault liegen wie alles andere.
Während KeepassXC auf dem Mac (wie auch Windows und Linux) zum Einsatz kommt, bietet es sich dann an den .kdbx-Vault mittels kompatiblem iOS Client - wie z.B. dem tollen Strongbox - einzusetzen - wofür die kostenlose Version völlig ausreicht.

Der QR-Code enthält genau das Secret (z.B. AAAATHPVAAAA7XMU) - das ist das 'Passwort' für TOTP, was in der 2FA-App gespeichert wird. Es gibt keinen Startwert. Das Secret im QR-Code ist identisch mit dem, was mein Skript als Parameter $1 bekommt.

Ach übrigens, mein Skript ist auch Open Source! Das machen die genannten Apps alle genauso.
Mir geht es darum, dass die Hintergründe klar sind. Selbst nutze ich Strongbox, also ein .kdbx-Vault.

"De-Googleings" ist eine eine sehr coole Wortschöpfung

Den restlichen Ansatz finde ich cool. Muss ich mir mal in Ruhe anschauen. Danke !

C.

Ich setze privat Cisco DUO ein, ist im Privatumfeld kostenlos.

Beruflich haben wir ein Vaultwarden ("Bitwarden on Prem"), der für uns Passwörter und Einmalcodes managed.
Privat habe ich einen Yubikey, auf dem die Secrets gespeichert sind. Die kann ich dann (PIN-geschützt) mit der Yubi Authenticator (gibt's für Win, Mac, iOS und Android) nutzen und habe sie an dem Gerät, wo ich sie gerade brauche.

Ich nutze Apple's Passwords dafür – funktioniert prima und ist immer sofort verfügbar auf allen Geräten. Kommt von Apple, wird synchronisiert. 👍🏻 Hebe das extra hervor, nachdem meine Auth App plötzlich komplett und ohne ersichtlichen Grund einige 2-Faktor-Authentifizierungen gesperrt hat. Nix ging mehr, war sehr mühsam und nicht nahvollziehbar (andere gingen noch).

2FAS - what else ( synchronisiert auch über iCloud gegen andere Geräte sehr gut [Tablet etc.])

Die APPLE PWD-App hat mich mal voll in die Pfanne gehauen, von gestern auf heute wurden diese 6Digits zur 2FA nicht mehr angezeigt - Panik ( und jetzt hab ich vor jeden Apple-Update einen Horror bezüglich der 2FA Digits, dass die dann man nicht mehr angezeigt werden ).

Mit 2FAS jetzt wesentlich ruhiger unterwegs, zumal das richtig gut zwischen anderden Apple-Devices super sauber synchronisiert ...

Es muss lediglich das Secret (das Passwort zum TOTP, dargestellt als QR-Code) synchronisiert werden. Die 6-stelligen Zahlencodes werden nicht synchronisiert. Wer nicht täglich einen neuen QR-Code/Secret erstellt, muss gar nichts synchronisieren außer neu angelegte Passwörter. Aber 2FA hat man in der Regel doch bloß so für 20 Konten ...
Die Berechnung ist einfach nur: Secret + Zeitstempel => 6-stelliger Code

Das wird alles lokal berechnet, keine Freischaltung, kein Sync von Codes.

Das wusste ich nicht. Ist ja noch besser. Stelle gerade auf Apple Passwörter um. Klappt wunderbar.

Ein kurzes Follow-Up: Ich habe nun für ein paar Dienste 2FA eingerichtet und dabei alles über Enpass abgewickelt -- das ist eh eine App, die ich im Einsatz habe und kenne.
Ich hatte ehrlich gesagt etwas Muffensausen, weil ich vorher in einschlägigen Foren Horrormeldungen gelesen habe a la "Kann mich nach der Umstellung nicht mehr an meiner Synology anmelden" -- aber es ging alles problemlos und schmerzfrei über die Bühne.
Danke nochmal an die rege Diskussionsteilnahme!

Nutze seit Jahren 2FAS

Hello,

hab# den Threat etwas aus den Augen verloren…

Ich habe mal ein paar Seiten zu dem Thema überflogen und konnte bei KEINER ersehen, dass das Passwort als Startwert genutzt wird. Ja, okay, kann an den Seiten liegen… Dennoch würde ich das Thema mal etwas genauer betrachten und verstehen, denn so wie Du es schilderst, ergibt es ja keinen wirklichen Sinn, dass Passwort mit einzubauen. Denn letztlich würde ich ja nur das Passwort 2x eingeben…

So ich das verstehe, nimmt bspw. eine Webseite einen Secret ( bspw. HASH-Wert oder SSL oder … ), der eben nur der Seite bekannt ist, kombiniert ihn mit einem Zeitstempel, berechnet Dir Dein QR-Code, den du scannst und der dann gemäß App Dir den OTP anzeigt. Den kann die Seite verarbeiten, da sie ja »auf das Secret zurückrechnen kann«. Also, mal so ganz grob…

Da ich mich nie wirklich mit Skript befasst habe, kann ich das nicht/nur etwas nachvollziehen. Ja, logisch ist natürlich, dass es immer funktioniert, wenn man das Passwort als Basis ( $1 bei Dir ) nimmt – dann kommt »das richtige Ergebnis raus«.

Hast Du mal eine Quelle, die das Konzept sachlich erklärt ?? Beim BSI & Co ist es ja schön konsumentenfreundlich bebildert, aber die Algorithmen dahinter nicht so wirklich
Bei Wikipedia gibt es eine Menge an Quelle – vielleicht eine Empfehlung ??

Danke, Happy Start in die Woche allen !! C.

Der offizielle Standard ist RFC 6238: https://datatracker.ietf.org/doc/html/rfc6238

Die Funktionsweise:
Beide Seiten - die Website und Du - haben das gleiche Secret (z.B. AAAATHPVAAAA7XMU). Das Secret wird beim Setup einmalig über den QR-Code übertragen und dann von beiden gespeichert.

Der Clou bei TOTP ist, dass nicht das Secret selbst übertragen wird, sondern aus dem Secret + Zeitstempel ein 6-stelliger Zahlencode generiert wird (siehe mein Skript oben). So können beide Seiten - Website und Du - den gleichen Code ausrechnen, ohne das Secret preiszugeben.

Ein Dritter aber ist nicht in der Lage, das Secret abzuphishen, da er immer nur den temporären 6-stelligen Zahlencode sieht. Selbst wenn jemand den Code abfängt, ist er nach 30 Sekunden wertlos. Und selbst aus 50 Codes hintereinander kann der Man in the Middle das Secret nicht rekonstruieren.
hier noch das, was mein Skript macht:
Zeile 1: Secret von Base32 zu Hex dekodieren
Zeile 2: Aktuellen Unix-Zeitstempel durch 30 teilen und als 16-stellige Hex-Zahl formatieren (30-Sekunden-Zeitfenster)
Zeile 3: HMAC-SHA1 Hash aus Zeitstempel + Secret berechnen
Zeile 4: Offset aus dem Hash bestimmen (Dynamic Truncation nach RFC 6238)
Zeile 5: 4 Bytes ab Offset extrahieren, höchstes Bit entfernen, Modulo 1 Million = 6-stelliger Code

sudoRinger: Dank Dir für die Antwort. Werde mal etwas lesen. Greetings, C.

Für macOS KeePassXC für i-Devices KeePassium.
Im KeePass 2.x Format die Datenbank anlegen und irgendwo ablegen, wo alle Geräte Zugriff haben. Kann sogar auf dem iCloud Drive sein. Da die Datenbank verschlüsselt ist kommt niemand ohne das Masterpasswort direkt an die Daten. Zudem kann man es schnell und einfach am Mac befüllen und es bringt ein OTP mit.

FreeOTP von RedHat https://apps.apple.com/us/app/freeotp-authenticator/id872559395

Ich habe nochmal überlegt, wie viele TOTP-Codes man mitlesen muss, um das Secret zurückzurechnen. Das dauert bei einem Secret aus 24 Ziffern (Base32) nur 6 Runden. 32^24 = 2^120 Möglichkeiten. Jede Runde bleibt 1/1.000.000 ≈ 1/2^20 übrig. Also 120/20 = 6 Runden (und keine 50 Runden, sorry). Also nur 3 Minuten. Das geht recht flott, oder?

Aber das sind rund 10^36 Hash-Berechnungen. Bei 1 Mrd. Berechnungen pro Sekunde sind das so 3×10^16 Berechnungen pro Jahr. Macht pi mal Daumen etwa 3×10^19 Jahre. Das Zurückrechnen dauert dann anschließend wohl doch etwas länger ...

2FA aktiviert zu haben ist definitiv besser als gar nicht. Aber wie jeder weiss gibt es keine 100% Sicherheit.

Ich kenne einige Leute, deren Accounts trotz 2FA gehackt wurden. Denn in der Realität (zumindest bei mehreren Fällen von denen ich mitbekommen habe) wird 2FA selber gar nicht angegriffen - zudem sitzt eines der Hauptprobleme auch oft vor dem Monitor, das massgeblich dazu beiträgt
Im Zusammenspiel gewisser Umstände ist erscheint es simpler als man denkt. Zu diesen Umständen gehört, dass ein Dienste-Anbieter anbietet den 2FA Token via Email als Transportweg zu verschicken. Diese Option wählen einige User - dumm nur ist, wenn der Loginname und die für das Verschicken des Tokens genutzte Emailadresse dieselbe ist (abgesehen davon, dass der Emailtransportweg - bei Vorhandensein weiterer Wege - der schlechtestmögliche ist). In den mir bekannten Fällen kommt ganz wesentlich zum Tragen aber auch, dass das Emailkonto bereits gekapert wurde (wie es dazu wiederum kam, steht auf einem anderen Blatt, aber ist natürlich essentiell bei diesen Kontenhacks, was aber sehr sehr oft vorkommt). Die Kriminellen brauchen sich so überhaupt keinen Kopf machen, wie sie die 2FA Hürde nehmen, wenn sie einfach die eingegangene Email mit dem Token auslesen.

sudRinger
Nochmals zu dem Thema Secret. Ich habe mir eine Zusammenfassung aus der Übersetzung basteln lassen und die sehr(!) kurz überflogen. Damit ergibt es m.M.n. überhaupt keinen Sinn, das Passwort ( bspw. meines MTN-Accounts als Secret für die Berechnung der 2FA für den Login der MTN-Webseite ) zu nutzen. Naja, so wie ich es verstehe…

Passwort: vom Benutzer gewählt, oft schwächer, kann zurückgesetzt werden.
TOTP-Schlüssel (Secret Key K): vom Server zufällig generiert, hochentropisch, dient nur für die Einmalpasswörter (OTP).

Diese beiden Geheimnisse haben nichts miteinander zu tun.
Das Passwort ist nicht der Schlüssel, der zur Berechnung der TOTP-Codes verwendet wird – denn wäre er es, so müsstest Du zudem IMMER den 2FA neu machen, wenn Du Dein Passwort änderst, denn berechnete TOTP wäre ja immer falsch… Oder ???

Happy Evening, C.
PS: 20.34 Uhr – noch steht's 0:0

Ja, genau. Das ergibt keinen Sinn und so wird es auch nicht gemacht.

Nochmal ganz langsam: Du vergibst Benutzername und Passwort.
Die Website gibt dir ein Secret (ein Buchstaben-Zahlen-Code), meist als QR-Code. Dieses Secret hat nichts mit deinem Passwort zu tun. Aus dem Secret werden dann die sechsstelligen TOTP-Codes berechnet. Website und App gleichen die Codes ab und wissen so, dass beide das gleiche Secret kennen.

So hatte ich es auch verstanden, habe ich Dich oben wohl einfach falsch verstanden. Denn ich hatte es so gelesen, als wenn der QR-Code das selbstvergebene PWD + Time enthält – und war deshalb irritiert, wo ich im Resthirn den Fehler hatte.

Danke für laaaaangsame Erleuchten

Sag niemals nie > 2FA ( das mit dem "Ab-Phishen" ) >> https://winfuture.de/news,154244.html

Oh Mist, jetzt ist die Hintertür aufgeflogen.

Ja, 100%-ige Sicherheit gibt es eben nicht…
Dennoch schon mal gut, dass es anscheinend erst einmal nur Android betrifft… Wohlweislich nutze ich »anscheinend«…

Und dann können wir uns ja schon einmal bei der EU bedanken, die die Sicherheit Dank der Zwangsöffnung zusätzlicher App-Stores deutlich senkt… Und nein, es bedeutet im Umkehrschluß mit nichten, dass Apples App Store sicher ist…

Zumindest die Überlegung sollte – und das meine ich nicht nur spaßeshalber – einschliessen, wieder analog(er) zu arbeiten.

Greetings, C.

Vielleicht mag das für diesen speziellen Angriffsvektor (noch) so sein.
Aber was ist letztendlich das Ziel? Nicht das eigentliche 2FA-Abfischen, sondern um in einen Account zu gelangen (um dort dann was auch immer zu machen).

Und hier gibt es seit Jahren verschiedene Ansätze, einer davon ist - wie ich aus einem Gespräch mit einem Sicherheitsforscher vor einigen Jahren erfuhr - so einfach, dass sich ein bestimmtes Tool (oder Toolkategorie) zu einem sehr beliebten Instrument "in der Szene" gemausert hat, weil die Anwendung anscheinend so einfach sein soll. Ja, Personen mit entsprechender Aufmerksamkeit - und dazu würde ich das ganze Forum hier vermutlich zählen - würden nicht drauf reinfallen, aber der Otto Normalbenutzer eher schon.
An technische Details kann ich mich nicht mehr erinnern, würde auch etwas brauchen um den Namen dieses Werkzeugs wieder ausfindig zu machen, aber ganz grob (und ich kann hier gewisse technische Ungenauigkeiten meinerseits nicht ganz ausschliessen) handelt es sich im weiteren Sinne um einen MITM (man in the middle) Angriff, bei dem sich ganz regulär beim Dienst via der echten Login-Maske eingeloggt wird, der 2FA Token wird vom Benutzer ganz regulär dabei genutzt - die Angreifer brauchen den 2FA Mechanismus oder das 2FA-Gerät gar nicht angreifen dabei - da sie nach erfolgtem Login dann selbst in der Account Session drin sind.

Mit Verlaub, so eine Behauptung ist natürlich Unsinn.