2FA mit KeePass: seit "Login 2.0" nur noch SHA-1 TOTP möglich

einuser ●

Auch ich wurde gestern umgestellt, und bin etwas enttäuscht. Ich fand das alte System besser. Egal, meine Anforderungen sind vielleicht etwas speziell und nach der einmalig aufwändigen Umstellung, Umgewöhnung und Kontrolle sollte alles passen.

Die alte Version mit vierstelliger Pin und 2FA fand ich besser, unter anderem weil ich bei der 2FA individuell SHA512 und 8 Ziffern auswählen konnte. Auch hatte ich statt Hauptpasswort eine einfach zu merkende PIN. Damit habe ich mich sehr sicher gefühlt. Aktuell gibt es für die 2FA nur 6 Ziffer mit SHA1. Auch wenn SHA1 als unsicher gilt, so ist es in Zusammenhang mit TOTP wohl doch (noch?) sicher. Offenbar scheint der Sicherheitsgewinn zwischen 6 Ziffern mit SHA1 und 8 Ziffern mit SHA512 nach aktuellem (!) Stand nur marginal und akademisch zu sein. Ein Rückschluss von dem Mitlesen auch von mehreren 2FA-Codes auf das Geheimnis soll nicht möglich zu sein, egal welches SHA verwendet wird. Gefühlt fühle ich mich mit 8 Ziffern und SHA512 viel sicherer, da SHA1 als unsicher gilt, technisch kann ich die Einbindung von SHA1 in TOTP bei 2FA als Laie nicht nachvollziehen, also bleibt eben nur das Gefühl, was im Widerspruch zur technischen Realität ist.

Der Grund für die Umstellung war wohl eine generelle Umstellung bei mailbox.org beim Loginverfahren unabhängig von 2FA. Auch wurde die alte 2FA-Version mit PIN und das alte 2FA-Benutzermenü mit Funktionsvielfalt im Forum sehr häufig als zu kompliziert oder unverständlich kritisiert. Vielleicht haben sich viele Leute damit ausgesperrt, und einen hohen Supportaufwand bei mailbox.org erzeugt. Auch gab es im Forum den Wunsch nach App-Passwörtern, wie es andere Anbieter haben. Die Verringerung des Sicherheitsniveaus bei individueller Einstellung von SHA512 auf SHA1 und von 8 auf 6 Ziffern scheint nur ein marginaler und akademische Sicherheitsverlust zu sein, und bei mailbox.org wohl Rechenleistung zu sparen. 6 Ziffern sind auch schneller für den Ottonormal-User einzugeben als 8 Ziffern. Und das neue Single-Sign-On ist praktisch für Leute, die sich häufig im Forum und bei Videokonferenzen anmelden. Letztlich also vielleicht ein Kompromiss aus Usability (in meinen Worten Bequemlichkeit), Kundenwünschen, Sicherheit und geringer Supportaufwand. Schließlich ist mailbox.org gewinnorientiert und kein gemeinnütziges Unternehmen ... auch wenn es die Gewinnorientierung im Gegensatz zu vielen anderen Mailanbietern offensichtlich nicht an erste Stelle stellt, sondern noch echte Werte/Überzeugungen/Ethos (wie auch immer man es nennt) hat.

Für mich war existenziell, dass bei Verwendung bzw. Aktivierung von der neuen 2FA alle anderen Zugangswege, wie z.B. IMAP und SMTP aber auch Caldav/Carddav/Webdav verschlossen sind, und nur noch per separatem App-Passwort verwendbar sind. Sonst könnte mich ein Angreifer zum Beispiel mit der Passwort-Reset-Funktion per Mail sofort aussperren ... oder unbemerkt alle Daten auslesen bzw. löschen (Mails, Adressbücher, Kalender und Cloud). Das war bei der Betaphase anfangs anders, und auch im Produktivbetrieb gab es Fehler, wo das Hauptpasswort doch noch verwendbar war. Damit war die neue 2FA bei mailbox.org für mein Verständnis kompromittiert, da eine Einwahl von einem unsicheren PC aus mit einem einfach installierten Keylogger trotz 2FA einen dauerhaften Generalzugriff preisgegeben hätte. Einen Keylogger kann jeder Laie installieren, dazu brauche ich keinen Geheimdienst und keine IT-Fachexpertise. Gerade für die Einwahl auf unsicheren Geräten ist aber die 2FA gedacht! Der Fehler scheint mittlerweile behoben zu sein. Früher war halt das Einrichten der 2FA kompliziert, jetzt ist das Einrichten von nicht frei wählbaren App-Passwörtern an zwei unterschiedlichen Stellen im Menü kompliziert. Für mich kein Vorteil sondern eine Umstellung von einem gut funktionierenden Setup auf etwas neues, für den Standardnutzer von mailbox.org offenbar in der Gesamtschau aller Änderungen ein Vorteil.

Auch ich wurde gestern umgestellt, und bin etwas enttäuscht. Ich fand das alte System besser. Egal, meine Anforderungen sind vielleicht etwas speziell und nach der einmalig aufwändigen Umstellung, Umgewöhnung und Kontrolle sollte alles passen.

Die alte Version mit vierstelliger Pin und 2FA fand ich besser, unter anderem weil ich bei der 2FA individuell SHA512 und 8 Ziffern auswählen konnte. Auch hatte ich statt Hauptpasswort eine einfach zu merkende PIN. Damit habe ich mich sehr sicher gefühlt. Aktuell gibt es für die 2FA nur 6 Ziffer mit SHA1. Auch wenn SHA1 als unsicher gilt, so ist es in Zusammenhang mit TOTP wohl doch (noch?) sicher. Offenbar scheint der Sicherheitsgewinn zwischen 6 Ziffern mit SHA1 und 8 Ziffern mit SHA512 nach aktuellem (!) Stand nur marginal und akademisch zu sein. Ein Rückschluss von dem Mitlesen auch von mehreren 2FA-Codes auf das Geheimnis soll nicht möglich zu sein, egal welches SHA verwendet wird. Gefühlt fühle ich mich mit 8 Ziffern und SHA512 viel sicherer, da SHA1 als unsicher gilt, technisch kann ich die Einbindung von SHA1 in TOTP bei 2FA als Laie nicht nachvollziehen, also bleibt eben nur das Gefühl, was im Widerspruch zur technischen Realität ist.

Der Grund für die Umstellung war wohl eine generelle Umstellung bei mailbox.org beim Loginverfahren unabhängig von 2FA. Auch wurde die alte 2FA-Version mit PIN und das alte 2FA-Benutzermenü mit Funktionsvielfalt im Forum sehr häufig als zu kompliziert oder unverständlich kritisiert. Vielleicht haben sich viele Leute damit ausgesperrt, und einen hohen Supportaufwand bei mailbox.org erzeugt. Auch gab es im Forum den Wunsch nach App-Passwörtern, wie es andere Anbieter haben. Die Verringerung des Sicherheitsniveaus bei individueller Einstellung von SHA512 auf SHA1 und von 8 auf 6 Ziffern scheint nur ein marginaler und akademische Sicherheitsverlust zu sein, und bei mailbox.org wohl Rechenleistung zu sparen. 6 Ziffern sind auch schneller für den Ottonormal-User einzugeben als 8 Ziffern. Und das neue Single-Sign-On ist praktisch für Leute, die sich häufig im Forum und bei Videokonferenzen anmelden. Letztlich also vielleicht ein Kompromiss aus Usability (in meinen Worten Bequemlichkeit), Kundenwünschen, Sicherheit und geringer Supportaufwand. Schließlich ist mailbox.org gewinnorientiert und kein gemeinnütziges Unternehmen ... auch wenn es die Gewinnorientierung im Gegensatz zu vielen anderen Mailanbietern offensichtlich nicht an erste Stelle stellt, sondern noch echte Werte/Überzeugungen/Ethos (wie auch immer man es nennt) hat.

Für mich war existenziell, dass bei Verwendung bzw. Aktivierung von der neuen 2FA alle anderen Zugangswege, wie z.B. IMAP und SMTP aber auch Caldav/Carddav/Webdav verschlossen sind, und nur noch per separatem App-Passwort verwendbar sind. Sonst könnte mich ein Angreifer zum Beispiel mit der Passwort-Reset-Funktion per Mail sofort aussperren ... oder unbemerkt alle Daten auslesen bzw. löschen (Mails, Adressbücher, Kalender und Cloud). Das war bei der Betaphase anfangs anders, und auch im Produktivbetrieb gab es Fehler, wo das Hauptpasswort doch noch verwendbar war. Damit war die neue 2FA bei mailbox.org für mein Verständnis kompromittiert, da eine Einwahl von einem unsicheren PC aus mit einem einfach installierten Keylogger trotz 2FA einen dauerhaften Generalzugriff preisgegeben hätte. Einen Keylogger kann jeder Laie installieren, dazu brauche ich keinen Geheimdienst und keine IT-Fachexpertise. Gerade für die Einwahl auf unsicheren Geräten ist aber die 2FA gedacht! Der Fehler scheint mittlerweile behoben zu sein. Früher war halt das Einrichten der 2FA kompliziert, jetzt ist das Einrichten von nicht frei wählbaren App-Passwörtern an zwei unterschiedlichen Stellen im Menü kompliziert. Für mich kein Vorteil sondern eine Umstellung von einem gut funktionierenden Setup auf etwas neues, für den Standardnutzer von mailbox.org offenbar in der Gesamtschau aller Änderungen ein Vorteil.

Antworten URL

1

Walter H. ●

mich hat es gerstern eiskalt erwischt; zuvor hatte ich den 4 stelligen PIN im Kopf und ein paar Ziffern durch den TOTP-Generator und das wars;

und das Passwort hatte ich

- f. SMTP
- f. IMAP
- f. WebDAV um von Linux auf das Drive zuzugreifen
- f. Thunderbird [am PC] um den Kalender einzubinden
- f. OXDrive am Phone
- f. DAVx5 am Phone

die so generierten Applikations-Passwörter sind ja nicht schlecht,
aber eine Challenge ist es schon, das SMTP/IMAP-Passwort auf das Phone zu bringen ...

wie ich ja geschrieben habe wofür bisher das Passwort verwendet wurde,
dass hier jetzt aber
f. die Einbindung des Kalender in Thunderbird am PC und
f. DAVx5 f. die Kontaktesynchronisation am Phone
2 unterschiedliche Passwörter haben kann, obwohl die 'gleiche' Applikation,
nämlich 'Kalender- und Adressbuch-Client (CalDAV/CardDAV)'
ist dann nicht selbstverständlich;

aber auch, dass es hier um unterschiedliche 'Applikationen' geht,
einmal der Zugriff auf das Drive mittels OXDrive am Phone und
einmal der Zugriff auf das Drive via davfs2 unter Linux
ist nicht wirklich logisch;
ersteres ist die Applikation 'Drive Sync-App' und zweiteres
die Applikation 'WebDAV-Client', so sieht es jetzt bei mir aus

00f5f56e62c331fa3855582893a33bee

zu der Geschichte mit TOTP und SHA1, SHA224, ...

im Prinzip ist es vollkommen egal, es könnte genausogut MD4 od. MD5 sein,
der Sicherheitsgewinn durch SHA512 ist nur akademisch ;-)

warum?

OTP ist vom Konzept so definiert, dass an Hand eines definierten Keys Einmalpasswörter generiert werden;

HOTP [falls das noch wo in Verwendung ist, bitte ein Beispiel bringen], zählt die Events einfach nach oben;
sprich hier hat man tatsächlich die Möglichkeit, sollte jemand diese der Reihe nach abfangen auf den Key rückzurechnen, wenn das Hashverfahren schwach ist;
aber genau so schnell sperrt man sich aber auch aus; es braucht nur aus unerfindlichen Gründen ein Problem dahingehend bestehen, dass der Server nicht mitbekommen hat, dass das nächste Passwort an der Reihe war;
und somit sind die Counter asynchron ...

bei TOTP, ist das ganze ja zeitgesteuert und das Einmalpasswort hat eine Gültigkeit von 30 Sekunden [reicht vollkommen]; hïer muss nur sichergestellt sein, dass der Passwortgenerator und der Server zeitsynchron laufen; dieses 'Aussperren' wie darüber beschrieben ist hier nicht möglich;

sollte bei TOTP es tatsächlich jemand gelingen die Einmalpasswörter abzufangen, dann hat er nur dann eine Chance auf den Key rückzurechnen, wenn er auch den jeweiligen internen Counter dazu kennt ...

mich hat es gerstern eiskalt erwischt; zuvor hatte ich den 4 stelligen PIN im Kopf und ein paar Ziffern durch den TOTP-Generator und das wars;

und das Passwort hatte ich

- f. SMTP
- f. IMAP
- f. WebDAV um von Linux auf das Drive zuzugreifen
- f. Thunderbird [am PC] um den Kalender einzubinden
- f. OXDrive am Phone
- f. DAVx5 am Phone

die so generierten Applikations-Passwörter sind ja nicht schlecht,
aber eine Challenge ist es schon, das SMTP/IMAP-Passwort auf das Phone zu bringen ...

wie ich ja geschrieben habe wofür bisher das Passwort verwendet wurde,
dass hier jetzt aber
f. die Einbindung des Kalender in Thunderbird am PC und
f. DAVx5 f. die Kontaktesynchronisation am Phone
2 unterschiedliche Passwörter haben kann, obwohl die 'gleiche' Applikation,
nämlich 'Kalender- und Adressbuch-Client (CalDAV/CardDAV)'
ist dann nicht selbstverständlich;

aber auch, dass es hier um unterschiedliche 'Applikationen' geht,
einmal der Zugriff auf das Drive mittels OXDrive am Phone und
einmal der Zugriff auf das Drive via davfs2 unter Linux
ist nicht wirklich logisch;
ersteres ist die Applikation 'Drive Sync-App' und zweiteres
die Applikation 'WebDAV-Client', so sieht es jetzt bei mir aus

00f5f56e62c331fa3855582893a33bee

zu der Geschichte mit TOTP und SHA1, SHA224, ...

im Prinzip ist es vollkommen egal, es könnte genausogut MD4 od. MD5 sein,
der Sicherheitsgewinn durch SHA512 ist nur akademisch ;-)

warum?

OTP ist vom Konzept so definiert, dass an Hand eines definierten Keys Einmalpasswörter generiert werden;

HOTP [falls das noch wo in Verwendung ist, bitte ein Beispiel bringen], zählt die Events einfach nach oben;
sprich hier hat man tatsächlich die Möglichkeit, sollte jemand diese der Reihe nach abfangen auf den Key rückzurechnen, wenn das Hashverfahren schwach ist;
aber genau so schnell sperrt man sich aber auch aus; es braucht nur aus unerfindlichen Gründen ein Problem dahingehend bestehen, dass der Server nicht mitbekommen hat, dass das nächste Passwort an der Reihe war;
und somit sind die Counter asynchron ...

bei TOTP, ist das ganze ja zeitgesteuert und das Einmalpasswort hat eine Gültigkeit von 30 Sekunden [reicht vollkommen]; hïer muss nur sichergestellt sein, dass der Passwortgenerator und der Server zeitsynchron laufen; dieses 'Aussperren' wie darüber beschrieben ist hier nicht möglich;

sollte bei TOTP es tatsächlich jemand gelingen die Einmalpasswörter abzufangen, dann hat er nur dann eine Chance auf den Key rückzurechnen, wenn er auch den jeweiligen internen Counter dazu kennt ...

Antworten URL

2

lufer ●

dass hier jetzt aber
f. die Einbindung des Kalender in Thunderbird am PC und
f. DAVx5 f. die Kontaktesynchronisation am Phone
2 unterschiedliche Passwörter haben kann, obwohl die 'gleiche' Applikation,

Genau das ist der Sinn der Sache, jeder Client ein eigenes Passwort, um sie im Kompromitierungsfall einzeln widerrufen zu können.

TOTP ist lediglich ein Spezialfall von HOTP, siehe RFC6238, ist also genauso sicher oder unsicher wie HOTP.

HOTP wird übrigens durchaus noch in der "Reinform" verwendet:

Überall, wo mind. eine der zwei beteiligten Seiten keine zuverlässige Uhrzeit hat (keine Uhr vorhanden, geht verloren bei Stromausfall, geht falsch etc.).
Z.B. bei Smartcards oder stark abgeschotteten Systemen.
Wenn die genaue Uhrzeit des Login-Vorgangs nicht vorher bekannt ist und die Generierung des OTP nicht instant ist.
Z.B. Das Secret ist in einem HSM gespeichert, MA kann OTP generieren lassen, Eingabe erfolgt aber irgendwo, wo wahlweise kein WiFi/Internet/Mobilfunk vorhanden ist.
Oder MA hat TOTP-App auf Smartphone, aber am Eingabepunkt sind keine Smartphones erlaubt (Firmen-Policy in streng geschütztem Bereich).

Das mit den Countern ist auch kein Problem, denn die sind nicht geheim, weder bei HOTP noch TOTP, der Server kann den gewünschten Counter anzeigen oder auch problemlos höhere Counter akzeptieren.

sollte bei TOTP es tatsächlich jemand gelingen die Einmalpasswörter abzufangen, dann hat er nur dann eine Chance auf den Key rückzurechnen, wenn er auch den jeweiligen internen Counter dazu kennt ...

Und genau diesen kennt jeder (Client/Server/Angreifer/...), denn er ist trivial aus der aktuellen Uhrzeit herzurechnen.

Der Grund, wieso SHA1 mit OTP nicht komplett unsicher ist, ist, dass Kollisionen in diesem Szenario kein großes Probem darstellen.

dass hier jetzt aber
f. die Einbindung des Kalender in Thunderbird am PC und
f. DAVx5 f. die Kontaktesynchronisation am Phone
2 unterschiedliche Passwörter haben kann, obwohl die 'gleiche' Applikation,

Genau das ist der Sinn der Sache, jeder Client ein eigenes Passwort, um sie im Kompromitierungsfall einzeln widerrufen zu können.

TOTP ist lediglich ein Spezialfall von HOTP, siehe RFC6238, ist also genauso sicher oder unsicher wie HOTP.

HOTP wird übrigens durchaus noch in der "Reinform" verwendet:

Überall, wo mind. eine der zwei beteiligten Seiten keine zuverlässige Uhrzeit hat (keine Uhr vorhanden, geht verloren bei Stromausfall, geht falsch etc.).
Z.B. bei Smartcards oder stark abgeschotteten Systemen.
Wenn die genaue Uhrzeit des Login-Vorgangs nicht vorher bekannt ist und die Generierung des OTP nicht instant ist.
Z.B. Das Secret ist in einem HSM gespeichert, MA kann OTP generieren lassen, Eingabe erfolgt aber irgendwo, wo wahlweise kein WiFi/Internet/Mobilfunk vorhanden ist.
Oder MA hat TOTP-App auf Smartphone, aber am Eingabepunkt sind keine Smartphones erlaubt (Firmen-Policy in streng geschütztem Bereich).

Das mit den Countern ist auch kein Problem, denn die sind nicht geheim, weder bei HOTP noch TOTP, der Server kann den gewünschten Counter anzeigen oder auch problemlos höhere Counter akzeptieren.

sollte bei TOTP es tatsächlich jemand gelingen die Einmalpasswörter abzufangen, dann hat er nur dann eine Chance auf den Key rückzurechnen, wenn er auch den jeweiligen internen Counter dazu kennt ...

Und genau diesen kennt jeder (Client/Server/Angreifer/...), denn er ist trivial aus der aktuellen Uhrzeit herzurechnen.

Der Grund, wieso SHA1 mit OTP nicht komplett unsicher ist, ist, dass Kollisionen in diesem Szenario kein großes Probem darstellen.

URL

1

lufer ●

removed - s.u.

URL

1

Walter H. ●

@lufer

"Genau das ist der Sinn der Sache, jeder Client ein eigenes Passwort, um sie im Kompromitierungsfall einzeln widerrufen zu können."

damit hast hier aber auch glztg. den Angriffsvektor multipliziert;

warum?

wie ich ja geschrieben habe, dass ich

f. die Einbindung des Kalender in Thunderbird am PC und
f. DAVx5 f. die Kontaktesynchronisation am Phone
2 unterschiedliche Passwörter haben kann, obwohl die 'gleiche' Applikation,

heißt das nichts anders, dass man gar nicht wirklich exakt sagen, dass z.B. der Thunderbird am PC 'komprimitiert' wurde, weil die Passwörter f. DAVx5 und das f. Thunderbird vertauscht werden können - ist ja die selbe/gleiche 'Applikation';

oder anders: hast Du mit einen Client ein Problem, musst Du alle Passwörter, welcher zur gleichen 'Applikation' gehören neu vergeben;

und es unerheblich ist, ob jeder Client hier sein eigenes Passwort hat oder alle das gleiche;

ich meine dass Passwort f. SMTP/IMAP ist schon sehr komplex, aber sollte es jemand schaffen, an dieses zu kommen, kann er nicht nur die Mails einsehen, er kann auch Mails versenden;
wären hier jeweils ein Passwort f. SMTP und eines f. IMAP, wäre das eine echte Erhöhung der Sicherheit;

zu den Begriffen, welche ich da oben im Bildschirmabbild nicht maskiert habe: Phone, Linux, Thunderbird;
diese sind Schall- und Rauch, könnten auch Begriffe wie Keleti, Déli od. Nyugati stehen;

@lufer

"Genau das ist der Sinn der Sache, jeder Client ein eigenes Passwort, um sie im Kompromitierungsfall einzeln widerrufen zu können."

damit hast hier aber auch glztg. den Angriffsvektor multipliziert;

warum?

wie ich ja geschrieben habe, dass ich

f. die Einbindung des Kalender in Thunderbird am PC und
f. DAVx5 f. die Kontaktesynchronisation am Phone
2 unterschiedliche Passwörter haben kann, obwohl die 'gleiche' Applikation,

heißt das nichts anders, dass man gar nicht wirklich exakt sagen, dass z.B. der Thunderbird am PC 'komprimitiert' wurde, weil die Passwörter f. DAVx5 und das f. Thunderbird vertauscht werden können - ist ja die selbe/gleiche 'Applikation';

oder anders: hast Du mit einen Client ein Problem, musst Du alle Passwörter, welcher zur gleichen 'Applikation' gehören neu vergeben;

und es unerheblich ist, ob jeder Client hier sein eigenes Passwort hat oder alle das gleiche;

ich meine dass Passwort f. SMTP/IMAP ist schon sehr komplex, aber sollte es jemand schaffen, an dieses zu kommen, kann er nicht nur die Mails einsehen, er kann auch Mails versenden;
wären hier jeweils ein Passwort f. SMTP und eines f. IMAP, wäre das eine echte Erhöhung der Sicherheit;

zu den Begriffen, welche ich da oben im Bildschirmabbild nicht maskiert habe: Phone, Linux, Thunderbird;
diese sind Schall- und Rauch, könnten auch Begriffe wie Keleti, Déli od. Nyugati stehen;

URL

2

lufer ●

damit hast hier aber auch glztg. den Angriffsvektor multipliziert;

Sorry, aber das ist falsch. Wieso soll der Angriffsvektor größer sein?

Auch verstehe ich deine Argumentation bzgl. gleicher Applikation nicht. Gleiche Applikation ist z.B. Thunderbird für SMTP/IMAP und CalDAV/CardDAV. Hier bringen unterschiedliche Passwörter nichts, aber ist leider aktuell nicht anders zu lösen.

Dein obiges Beispiel ist nur das gleiche Protokoll.

Beispiel: Ich verliere mein Handy. Ich revoke das E-Mail-App-Passwort für FairEmail und das für den Kalender (z.B. DAVx5). Fertig. Bei geteiltem Passwort muss ich jetzt in x Clients ebenfalls Passwörter ändern.

ich meine dass Passwort f. SMTP/IMAP ist schon sehr komplex, aber sollte es jemand schaffen, an dieses zu kommen, kann er nicht nur die Mails einsehen, er kann auch Mails versenden;
wären hier jeweils ein Passwort f. SMTP und eines f. IMAP, wäre das eine echte Erhöhung der Sicherheit;

Das Passwort ist ausreichend komplex, sodass Brute Force keinen praktischen Angriffsvektor liefert.

Du kannst Token nur für IMAP oder auch nur für SMTP anlegen. Macht natürlich keinen Sinn, wenn die gleiche Anwendung beides können soll, dann macht man einfacher ein Passwort für beide Protokolle.

damit hast hier aber auch glztg. den Angriffsvektor multipliziert;

Sorry, aber das ist falsch. Wieso soll der Angriffsvektor größer sein?

Auch verstehe ich deine Argumentation bzgl. gleicher Applikation nicht. Gleiche Applikation ist z.B. Thunderbird für SMTP/IMAP und CalDAV/CardDAV. Hier bringen unterschiedliche Passwörter nichts, aber ist leider aktuell nicht anders zu lösen.

Dein obiges Beispiel ist nur das gleiche Protokoll.

Beispiel: Ich verliere mein Handy. Ich revoke das E-Mail-App-Passwort für FairEmail und das für den Kalender (z.B. DAVx5). Fertig. Bei geteiltem Passwort muss ich jetzt in x Clients ebenfalls Passwörter ändern.

ich meine dass Passwort f. SMTP/IMAP ist schon sehr komplex, aber sollte es jemand schaffen, an dieses zu kommen, kann er nicht nur die Mails einsehen, er kann auch Mails versenden;
wären hier jeweils ein Passwort f. SMTP und eines f. IMAP, wäre das eine echte Erhöhung der Sicherheit;

Das Passwort ist ausreichend komplex, sodass Brute Force keinen praktischen Angriffsvektor liefert.

Du kannst Token nur für IMAP oder auch nur für SMTP anlegen. Macht natürlich keinen Sinn, wenn die gleiche Anwendung beides können soll, dann macht man einfacher ein Passwort für beide Protokolle.

URL

1

Walter H. ●

Sorry, aber das ist falsch. Wieso soll der Angriffsvektor größer sein?

Das ist schon richtig. Einfach Querdenken.

wie gesagt, hat der Angreifer das Passwort für den Zugfriff auf den Kalender vom Thunderbird, braucht er das f. DAVx5 f. die Kontakte gar nicht, er nimmt das vom Thunderbird;

darum ist es auch egal, ob Du f. beide das gleiche Passwort verwendest od. jeweils ein anderes;

zumal ja die UserId immer die gleiche ist ...

Das Passwort ist ausreichend komplex, sodass Brute Force keinen praktischen Angriffsvektor liefert.

Brute Force ist nicht immer das Mittel der Wahl; auch hier Querdenken; wenn Du z.B. am Phone ohnehin Mails nur liest, dann hat der Angreifer, wenn er das IMAP-Passwort hat, auch das SMTP-Passwort; ob Du das nun auf diesem Device verwendest od. nicht;

Sorry, aber das ist falsch. Wieso soll der Angriffsvektor größer sein?

Das ist schon richtig. Einfach Querdenken.

wie gesagt, hat der Angreifer das Passwort für den Zugfriff auf den Kalender vom Thunderbird, braucht er das f. DAVx5 f. die Kontakte gar nicht, er nimmt das vom Thunderbird;

darum ist es auch egal, ob Du f. beide das gleiche Passwort verwendest od. jeweils ein anderes;

zumal ja die UserId immer die gleiche ist ...

Das Passwort ist ausreichend komplex, sodass Brute Force keinen praktischen Angriffsvektor liefert.

Brute Force ist nicht immer das Mittel der Wahl; auch hier Querdenken; wenn Du z.B. am Phone ohnehin Mails nur liest, dann hat der Angreifer, wenn er das IMAP-Passwort hat, auch das SMTP-Passwort; ob Du das nun auf diesem Device verwendest od. nicht;

URL

2

lufer ●

wie gesagt, hat der Angreifer das Passwort für den Zugfriff auf den Kalender vom Thunderbird, braucht er das f. DAVx5 f. die Kontakte gar nicht, er nimmt das vom Thunderbird;

Das ist zwar richtig, aber trotzdem tue ich mich bei getrennten Passwörtern leichter eins zu widerrufen. Änderst du immer dein Passwort bisher, wenn du es an einem Client nicht mehr brauchst? Machen das alle anderen?

Der Vektor wird daher kleiner, nicht nennenswert, aber ein bisschen.

zumal ja die UserId immer die gleiche ist ...

Was kein Problem ist, die Sicherheit kommt ja nicht durch die Geheimhaltung der User ID. In der Schule/Uni oder Arbeit kennst du wahrscheinlich auch die Usernamen deiner Mitmenschen, hilft dir jetzt nicht nennenswert.

Brute Force ist nicht immer das Mittel der Wahl

Das ist mir vollkommen klar, deswegen schreibe ich es ja.

dann hat der Angreifer, wenn er das IMAP-Passwort hat, auch das SMTP-Passwort

Das habe ich oben schon geschrieben, dass dem nicht so ist. Leg doch mal ein E-Mail-App-Passwort an, dann siehst dus.

wie gesagt, hat der Angreifer das Passwort für den Zugfriff auf den Kalender vom Thunderbird, braucht er das f. DAVx5 f. die Kontakte gar nicht, er nimmt das vom Thunderbird;

Das ist zwar richtig, aber trotzdem tue ich mich bei getrennten Passwörtern leichter eins zu widerrufen. Änderst du immer dein Passwort bisher, wenn du es an einem Client nicht mehr brauchst? Machen das alle anderen?

Der Vektor wird daher kleiner, nicht nennenswert, aber ein bisschen.

zumal ja die UserId immer die gleiche ist ...

Was kein Problem ist, die Sicherheit kommt ja nicht durch die Geheimhaltung der User ID. In der Schule/Uni oder Arbeit kennst du wahrscheinlich auch die Usernamen deiner Mitmenschen, hilft dir jetzt nicht nennenswert.

Brute Force ist nicht immer das Mittel der Wahl

Das ist mir vollkommen klar, deswegen schreibe ich es ja.

dann hat der Angreifer, wenn er das IMAP-Passwort hat, auch das SMTP-Passwort

Das habe ich oben schon geschrieben, dass dem nicht so ist. Leg doch mal ein E-Mail-App-Passwort an, dann siehst dus.

URL

1

Walter H. ●

Das ist zwar richtig, aber trotzdem tue ich mich bei getrennten Passwörtern leichter eins zu widerrufen.

das ist halt nur die halbe Miete; darum ein sehr guter Vergleich, der zeigt, wie man sich dadurch in einer falschen Sicherheit glaubt;

wenn in einem Wohnblock von einer Wohnungtüre Schlüssel abhanden kommen, tauscht man nicht bloß die Zylinder der Wohnungstüre, sondern alle Zylinder, wo die Wohnungsschlüssel sperren; Stichwort: Zentralsperre

so auch hier: man widerruft nicht nur das eine Passwort, sondern alle Passwörter;

Änderst du immer dein Passwort bisher, wenn du es an einem Client nicht mehr brauchst?

hier bitte unterscheiden zwischen dem Fall, dass Du Dein Phone nicht mehr hast, weil verloren od. gestohlen od. Du Dein Phone einfach nicht mehr haben willst und weitergibst;

im ersteren Fall, ändert man sein Passwort, im zweiteren gibt es keine Indikation dafür, die Daten löscht man ja bevor man sein Phone weitergibt;

Der Vektor wird daher kleiner, nicht nennenswert, aber ein bisschen.

wie Du ja schon gestgestellt hast, dass das Passwort f. den Thunderbird Kalender auch für DAVx5 verwendet werden kann und auch umgekehrt;

stell Dir vor Du hast 2 Geldkarten, und Du kannst hier die PINs vice versa verwenden, sprich f. Karte 1 gehen dieselben 2 PINs wie f. Karte 2;

Du handhabst es aber nur so dass Du PIN 1 f. Karte 1 verwendest und PIN 2 f. Karte 2;

Dir kommt eine der beiden Karten abhanden; bist Du hier jetzt immer noch der Meinung, dass bei der Variante, dass 2 PINs funktionieren, dass dies den Angriffsvektor nicht vergrößert?

Das ist zwar richtig, aber trotzdem tue ich mich bei getrennten Passwörtern leichter eins zu widerrufen.

das ist halt nur die halbe Miete; darum ein sehr guter Vergleich, der zeigt, wie man sich dadurch in einer falschen Sicherheit glaubt;

wenn in einem Wohnblock von einer Wohnungtüre Schlüssel abhanden kommen, tauscht man nicht bloß die Zylinder der Wohnungstüre, sondern alle Zylinder, wo die Wohnungsschlüssel sperren; Stichwort: Zentralsperre

so auch hier: man widerruft nicht nur das eine Passwort, sondern alle Passwörter;

Änderst du immer dein Passwort bisher, wenn du es an einem Client nicht mehr brauchst?

hier bitte unterscheiden zwischen dem Fall, dass Du Dein Phone nicht mehr hast, weil verloren od. gestohlen od. Du Dein Phone einfach nicht mehr haben willst und weitergibst;

im ersteren Fall, ändert man sein Passwort, im zweiteren gibt es keine Indikation dafür, die Daten löscht man ja bevor man sein Phone weitergibt;

Der Vektor wird daher kleiner, nicht nennenswert, aber ein bisschen.

wie Du ja schon gestgestellt hast, dass das Passwort f. den Thunderbird Kalender auch für DAVx5 verwendet werden kann und auch umgekehrt;

stell Dir vor Du hast 2 Geldkarten, und Du kannst hier die PINs vice versa verwenden, sprich f. Karte 1 gehen dieselben 2 PINs wie f. Karte 2;

Du handhabst es aber nur so dass Du PIN 1 f. Karte 1 verwendest und PIN 2 f. Karte 2;

Dir kommt eine der beiden Karten abhanden; bist Du hier jetzt immer noch der Meinung, dass bei der Variante, dass 2 PINs funktionieren, dass dies den Angriffsvektor nicht vergrößert?

URL

1

lufer ●

wenn in einem Wohnblock von einer Wohnungtüre Schlüssel abhanden kommen, tauscht man nicht bloß die Zylinder der Wohnungstüre, sondern alle Zylinder, wo die Wohnungsschlüssel sperren; Stichwort: Zentralsperre

Das Setup hier ist mit einer elektronischen Schließanlage vergleichbar. Hier lösche ich an allen Zylindern, wo der Schlüssel berechtigt ist, die Schließberechtigung für genau diesen einen Schlüssel.

Wieso sollte ich die Schlüssel (Passwörter) aller anderen Bewohner ungültig machen? Oder auch nur die vom Mitbewohner in der selben Wohnung?

Wenn ich das täte, müsste ich ihnen ja alle neue Schlüssel zukommen lassen. Dass hierbei etwas schiefgeht und sich ein Fremder z.B. als einer der Nachbarn ausgibt und sich einen Schlüssel erschleicht, weil da die Identität nicht sauber geprüft wird oder der Schlüssel in den Briefkasten geworfen wird und ein Fremder ihn sich schnell holt und kopiert (die Schlüssel sind trivial kopierbar, damit es mit der Analogie passt, da Passwörter auch trivial kopierbar sind), und so weiter ist hier um ein vielfaches größer. Außerdem müssen alle Mieter zeitgleich den neuen Schlüssel griegen, man möchte ja keinen aussperren.

Im anderen Fall muss ich nun der einen Person einen neuen Schlüssel geben und fertig. Spart Zeit, Geld, Nerven und ist sicherer.

Wenn ich natürlich nur einen Schlüssel (Passwort) verwende, habe ich nicht die Möglichkeit, feingranular zu widerrufen.

im ersteren Fall, ändert man sein Passwort, im zweiteren gibt es keine Indikation dafür, die Daten löscht man ja bevor man sein Phone weitergibt;

Der erste Fall erfordert also das aufwendige Prozedere oben. Der zweite Fall ist vergleichbar mit dem, dass ich den Schlüssel irgendwo in die Müllhalde werfe. Die Chance, dass er gefunden und verwendet wird, ist sehr gering, aber nicht null. (= wie sicher hat man die Daten gelöscht.)

Besser ich tausche auch hier einfach den Zylinder/Schließberechtigung aus und das kann nicht zum Problem werden.

Dir kommt eine der beiden Karten abhanden; bist Du hier jetzt immer noch der Meinung, dass bei der Variante, dass 2 PINs funktionieren, dass dies den Angriffsvektor nicht vergrößert?

Wie wir beide festgestellt haben, ist Brute Force nicht praktikabel, da wir eine 60-stellige PIN haben (entspricht grob der Komplexität des E-Mail-App-Passwords). Auch wenn 1000 PINs funktionieren, ist es nicht unsicherer, da die Brute Force Chance immer noch nahe null ist.

Dafür habe ich aber den entscheidenden Vorteil, dass es Vorteile bei der Usability hat (getrennter Widerruf, s.o.). Das bedeutet, dass es i.d.R. auch häufiger so genutzt wird, wie gedacht und die Leute seltener alternative unsichere Wege suchen. Und dadurch mehr Sicherheit.

Ich empfehle man einen Blick zu z.B. OAuth 2.0. Auch dort, wenn verschiedene Clients die selben Scopes haben, wird das Token nicht geshared. Das hat schon seinen Grund.

wenn in einem Wohnblock von einer Wohnungtüre Schlüssel abhanden kommen, tauscht man nicht bloß die Zylinder der Wohnungstüre, sondern alle Zylinder, wo die Wohnungsschlüssel sperren; Stichwort: Zentralsperre

Das Setup hier ist mit einer elektronischen Schließanlage vergleichbar. Hier lösche ich an allen Zylindern, wo der Schlüssel berechtigt ist, die Schließberechtigung für genau diesen einen Schlüssel.

Wieso sollte ich die Schlüssel (Passwörter) aller anderen Bewohner ungültig machen? Oder auch nur die vom Mitbewohner in der selben Wohnung?

Wenn ich das täte, müsste ich ihnen ja alle neue Schlüssel zukommen lassen. Dass hierbei etwas schiefgeht und sich ein Fremder z.B. als einer der Nachbarn ausgibt und sich einen Schlüssel erschleicht, weil da die Identität nicht sauber geprüft wird oder der Schlüssel in den Briefkasten geworfen wird und ein Fremder ihn sich schnell holt und kopiert (die Schlüssel sind trivial kopierbar, damit es mit der Analogie passt, da Passwörter auch trivial kopierbar sind), und so weiter ist hier um ein vielfaches größer. Außerdem müssen alle Mieter zeitgleich den neuen Schlüssel griegen, man möchte ja keinen aussperren.

Im anderen Fall muss ich nun der einen Person einen neuen Schlüssel geben und fertig. Spart Zeit, Geld, Nerven und ist sicherer.

Wenn ich natürlich nur einen Schlüssel (Passwort) verwende, habe ich nicht die Möglichkeit, feingranular zu widerrufen.

im ersteren Fall, ändert man sein Passwort, im zweiteren gibt es keine Indikation dafür, die Daten löscht man ja bevor man sein Phone weitergibt;

Der erste Fall erfordert also das aufwendige Prozedere oben. Der zweite Fall ist vergleichbar mit dem, dass ich den Schlüssel irgendwo in die Müllhalde werfe. Die Chance, dass er gefunden und verwendet wird, ist sehr gering, aber nicht null. (= wie sicher hat man die Daten gelöscht.)

Besser ich tausche auch hier einfach den Zylinder/Schließberechtigung aus und das kann nicht zum Problem werden.

Dir kommt eine der beiden Karten abhanden; bist Du hier jetzt immer noch der Meinung, dass bei der Variante, dass 2 PINs funktionieren, dass dies den Angriffsvektor nicht vergrößert?

Wie wir beide festgestellt haben, ist Brute Force nicht praktikabel, da wir eine 60-stellige PIN haben (entspricht grob der Komplexität des E-Mail-App-Passwords). Auch wenn 1000 PINs funktionieren, ist es nicht unsicherer, da die Brute Force Chance immer noch nahe null ist.

Dafür habe ich aber den entscheidenden Vorteil, dass es Vorteile bei der Usability hat (getrennter Widerruf, s.o.). Das bedeutet, dass es i.d.R. auch häufiger so genutzt wird, wie gedacht und die Leute seltener alternative unsichere Wege suchen. Und dadurch mehr Sicherheit.

Ich empfehle man einen Blick zu z.B. OAuth 2.0. Auch dort, wenn verschiedene Clients die selben Scopes haben, wird das Token nicht geshared. Das hat schon seinen Grund.

URL

1

Walter H. ●

Das Setup hier ist mit einer elektronischen Schließanlage vergleichbar.

Nein ist es nicht; bei einer elektronischen Schließanlage, folgt nicht automatisch, dass wenn Schlüssel 1 die Tür 2 sperrt, auch Schlüssel 2 die Tür 1 sperrt; bei Applikationspasswörtern folgt aber automatisch, dass wenn Passwort 1 am Host 1 f. Dienst X verwendet wird, und Passwort 2 am Host 2 f. den gleichen Dienst X verwendet wird, dass den auch umgekehrt möglich ist;

Dein Denkfehler(!)

Wenn ich das täte, müsste ich ihnen ja alle neue Schlüssel zukommen lassen.

richtig erkannt, der Verlust von Schlüsseln kann bei einem zentralen Sperrsystem teuer sein.

Der erste Fall erfordert also das aufwendige Prozedere oben. Der zweite Fall ist vergleichbar mit dem, dass ich den Schlüssel irgendwo in die Müllhalde werfe.

Quatsch, wenn schon so: der erste Fall ist einfach, Du findest keinen Nachmieter, der Dir vertraut, auch alle Schlüssel zu übergeben; und beim zweiteren übergibst Du die Schlüssel einfach dem Nachmieter

... da wir eine 60-stellige PIN haben (entspricht grob der Komplexität des E-Mail-App-Passwords). Auch wenn 1000 PINs funktionieren, ist es nicht unsicherer, da die Brute Force Chance immer noch nahe null ist.

von Brute Force spricht keiner; wie gesagt die Zugangsdaten sind in Zeiten wie diesen immer öfter durch andere Wege in die Hände von unbefugten geraten;

Das Setup hier ist mit einer elektronischen Schließanlage vergleichbar.

Nein ist es nicht; bei einer elektronischen Schließanlage, folgt nicht automatisch, dass wenn Schlüssel 1 die Tür 2 sperrt, auch Schlüssel 2 die Tür 1 sperrt; bei Applikationspasswörtern folgt aber automatisch, dass wenn Passwort 1 am Host 1 f. Dienst X verwendet wird, und Passwort 2 am Host 2 f. den gleichen Dienst X verwendet wird, dass den auch umgekehrt möglich ist;

Dein Denkfehler(!)

Wenn ich das täte, müsste ich ihnen ja alle neue Schlüssel zukommen lassen.

richtig erkannt, der Verlust von Schlüsseln kann bei einem zentralen Sperrsystem teuer sein.

Der erste Fall erfordert also das aufwendige Prozedere oben. Der zweite Fall ist vergleichbar mit dem, dass ich den Schlüssel irgendwo in die Müllhalde werfe.

Quatsch, wenn schon so: der erste Fall ist einfach, Du findest keinen Nachmieter, der Dir vertraut, auch alle Schlüssel zu übergeben; und beim zweiteren übergibst Du die Schlüssel einfach dem Nachmieter

... da wir eine 60-stellige PIN haben (entspricht grob der Komplexität des E-Mail-App-Passwords). Auch wenn 1000 PINs funktionieren, ist es nicht unsicherer, da die Brute Force Chance immer noch nahe null ist.

von Brute Force spricht keiner; wie gesagt die Zugangsdaten sind in Zeiten wie diesen immer öfter durch andere Wege in die Hände von unbefugten geraten;

URL

1

lufer ●

bei einer elektronischen Schließanlage, folgt nicht automatisch, dass wenn Schlüssel 1 die Tür 2 sperrt, auch Schlüssel 2 die Tür 1 sperrt; bei Applikationspasswörtern folgt aber automatisch, dass wenn Passwort 1 am Host 1 f. Dienst X verwendet wird, und Passwort 2 am Host 2 f. den gleichen Dienst X verwendet wird, dass den auch umgekehrt möglich ist

Schlüssel = App-Passwort

Tür = Dienst

Person = Host

Natürlich gilt, dass wenn Schlüssel 1 von Person 1 Tür X schließt und Schlüssel 2 von Person 2 auch Tür X schließt, diese Personen ihren Schlüssel tauschen können und es weiterhin geht.

Trotzdem macht es Sinn, die Schlüsel unabhängig voneinander widerrufen (sperren) zu können.

von Brute Force spricht keiner; wie gesagt die Zugangsdaten sind in Zeiten wie diesen immer öfter durch andere Wege in die Hände von unbefugten geraten;

Ich glaube hier sind wir uns beide einig. Aber bei diesen anderen Wegen ist es komplett egal, ob ich nun 1 oder 10 Passwörter/Token habe, was die Argumentation mehrere davon wären unsicherer als eins, zunichte macht.

Für was plädierst du eigentlich? Weiterhin nur ein Passwort zu nehmen? Oder was ist dein bevorzugtes Setup?

bei einer elektronischen Schließanlage, folgt nicht automatisch, dass wenn Schlüssel 1 die Tür 2 sperrt, auch Schlüssel 2 die Tür 1 sperrt; bei Applikationspasswörtern folgt aber automatisch, dass wenn Passwort 1 am Host 1 f. Dienst X verwendet wird, und Passwort 2 am Host 2 f. den gleichen Dienst X verwendet wird, dass den auch umgekehrt möglich ist

Schlüssel = App-Passwort

Tür = Dienst

Person = Host

Natürlich gilt, dass wenn Schlüssel 1 von Person 1 Tür X schließt und Schlüssel 2 von Person 2 auch Tür X schließt, diese Personen ihren Schlüssel tauschen können und es weiterhin geht.

Trotzdem macht es Sinn, die Schlüsel unabhängig voneinander widerrufen (sperren) zu können.

von Brute Force spricht keiner; wie gesagt die Zugangsdaten sind in Zeiten wie diesen immer öfter durch andere Wege in die Hände von unbefugten geraten;

Ich glaube hier sind wir uns beide einig. Aber bei diesen anderen Wegen ist es komplett egal, ob ich nun 1 oder 10 Passwörter/Token habe, was die Argumentation mehrere davon wären unsicherer als eins, zunichte macht.

Für was plädierst du eigentlich? Weiterhin nur ein Passwort zu nehmen? Oder was ist dein bevorzugtes Setup?

URL

1

Walter H. ●

Schlüssel = App-Passwort
Tür = Dienst
Person = Host

auch hier ein Denkfehler; Person = Account, wenn schon;

Aber bei diesen anderen Wegen ist es komplett egal, ob ich nun 1 oder 10 Passwörter/Token habe

nein ist es nicht, es darf pro Account je App MAXIMAL EIN Passwort geben.

Für was plädierst du eigentlich? Weiterhin nur ein Passwort zu nehmen? Oder was ist dein bevorzugtes Setup?

eigentlich war v1 sicherer, warum?

ganz einfach, egal was/wie/wo komprimitiert wurde, Passwort ändern, und das wars;

weil alle Deine Zugänge auf einen Schlag gesperrt wurden;

wie gesagt, wenn ein Schlüssel komprimitiert wurde, muss überall wo dieser Schlüssel passt, etwas getan werden;

und genau da verliert man auf die Art leicht den Überblick;

weil der Case: "ich hab den Verdacht, dass da was nicht passt; ohne einen definiertem Anhaltspunkt, welches Passwort in falsche Hände geriet, bedeutet bei Dir was?"
(bei mir alle Passwörter widerrufen, und das kann genausogut nur ein einziges sein, was hier aber unmöglich ist)

Schlüssel = App-Passwort
Tür = Dienst
Person = Host

auch hier ein Denkfehler; Person = Account, wenn schon;

Aber bei diesen anderen Wegen ist es komplett egal, ob ich nun 1 oder 10 Passwörter/Token habe

nein ist es nicht, es darf pro Account je App MAXIMAL EIN Passwort geben.

Für was plädierst du eigentlich? Weiterhin nur ein Passwort zu nehmen? Oder was ist dein bevorzugtes Setup?

eigentlich war v1 sicherer, warum?

ganz einfach, egal was/wie/wo komprimitiert wurde, Passwort ändern, und das wars;

weil alle Deine Zugänge auf einen Schlag gesperrt wurden;

wie gesagt, wenn ein Schlüssel komprimitiert wurde, muss überall wo dieser Schlüssel passt, etwas getan werden;

und genau da verliert man auf die Art leicht den Überblick;

weil der Case: "ich hab den Verdacht, dass da was nicht passt; ohne einen definiertem Anhaltspunkt, welches Passwort in falsche Hände geriet, bedeutet bei Dir was?"
(bei mir alle Passwörter widerrufen, und das kann genausogut nur ein einziges sein, was hier aber unmöglich ist)

URL

2

lufer ●

Die zugrundeliegende Software hier bei mailbox.org (Keycloak) unterstützt natürlich problemlos auch andere Hashs als SHA1 und auch längere OTPs (z.B. 8 Ziffern).

Auch hat das ganze keine (nennenswert) größere Last auf den Servern oder ähnliches.

Das Problem wird einzig und allein sein, dass die Oberfläche zum Einrichten der 2FA das nicht als Option anbietet. Die ist ja von mailbox.org implementiert und soll ein einfaches Interface bieten.

Leider sind wir auf das beschränkt, was mailbox.org uns hier zur Verfügung stellt, da kein direkter Zugriff auf die Account Console von Keycloak möglich ist. Vllt. macht es Sinn, die für die "Expertenuser" zu öffnen? Ich weiß es nicht.

Grundsätzlich finde ich es schade, dass (zumindest bisher) von den vielen Möglichkeiten von Keycloak nur ein Bruchteil genutzt wird bzw. zur Verfügung steht.

Antworten URL

2FA mit KeePass: seit "Login 2.0" nur noch SHA-1 TOTP möglich

Antworten (3)