Dropbox erzwingt neue Passwörter

Das ist ja kein Thema. Die Zeit kann man in der Google Authenticator App ja synchroniseren.

Zum Vergrößern anklicken....

dazu ist eine Internetverbindung erforderlich und wie ich solche Krücken kenne, weicht es die Sicherheit wieder einmal zugunsten der usability auf.
Wenn die Google-Programmierer die Zeit-Synchronisation nicht im Griff haben greifen sie wie gewohnt gerne mal zu solchen Krücken.

Zum synchronisieren, ja. Ich musste das aber nie, da die Uhr auf dem Smartphone nie verstellt war.
Ergo geht es auch ohne Internet. Du brauchst ja auch Internet, um die App herunterzuladen.

Im Prinzip ist es doch aber auch egal Wichtiger ist doch die Frage, wie es der Google Authenticator in Verbindung mit Dropbox macht.

Die Sorge, dass die Secrets gestohlen werden, wird auch hier im Bezug auf Authenticator Apps genannt:
https://nakedsecurity.sophos.com/2014/11/14/understanding-the-options-2fa/

If a crook gets hold of the seed (either from your device or by hacking into the server), he can calculate any future login codes.

Zum Vergrößern anklicken....

Auch hier ein Beitrag: https://security.stackexchange.com/...securely-at-the-validating-server/24103#24103

Since you can't hash OTP seeds, this mitigation simply isn't available for OTP seeds -- so you'll have to use other methods to protect your OTP seeds

Zum Vergrößern anklicken....

Ich finde keine andere Vorgehensweise, die OTP-Secrets, die man per Authenticator App nutzt, gehashed zu verwahren.
So wie ich das sehe, ist hier das Risiko leider doch vorhanden. Man belehre mich gerne eines besseren

Gut möglich, wie gesagt ich kenne die genaue Implementation nicht. Da bin ich selbst überrascht, war mir nicht bewusst, dass dies so banal ist. Sorry für die 'Belehrung' in diesem Fall.
Ich benutze wenn möglich immer meinen Yubikey, dort ist das Secret relativ sicher.

Ich bin zwar auch schon ein paar Jährchen Entwickler, aber hier eben auch noch recht neu, daher schon möglich das ich hier eben einen Vorteil übersehen habe Was ich noch gelesen habe ist wohl, dass die 2FA-Secrets seperat vom Rest gespeichert werden und über einen eigenen 2FA-Dienst abgehandled werden.

HOTP/TOTP hat eben doch einfach nur den Sinn, Sicherheit auf Client und Transportebene zu haben.
Im Prinzip dennoch recht sinnvoll:
- Greift man das Password und das OTP ab, kein Login nach 30 Sek. möglich.
- Kommt man an die Daten auf dem Server, OTPs generierbar, aber Passwort gehashed nutzlos.

Passwörter jetzt noch über S-Key/HashChain, bietet für die Passwörter zusätzliche Sicherheit, auch wenn ich hier ein paar Probleme sehen würde. Dennoch danke für diesen Hinweis. Das hatte ich gar nicht mehr auf dem Schirm.

Und es ist sehr einfach zu implementieren, was bei Yubikeys nicht so easy ist.
Ich nutze aber auch mehrere Yubikeys Zusätzlich sensible Daten in der Cloud immer in einem Truecrypt-Container

EDIT:
Wenn man genau drüber nachdenkt, kann man aber dennoch OTP-Secrets irgendwie generieren, ohne sie speichern zu müssen. Aus bekannten und unbekannten Userdaten, verschiedene Werte, die sich anhand bestimmter Kriterien ändern, aber am Ende immer den gleichen Code erzeugen.

Beispiel: einen Random Seed in der Datenbank speichern. Dazu jetzt die Benutzer-ID, einen im Code hinterlegten Wert, der sich aus der Quersumme der Benutzer-ID ermittelt und so weiter. Daraus könnte man das Nacherzeugen jedenfalls deutlich schwerer machen, da eine geklaute Datenbank alleine nicht mehr reicht.

Aefan schrieb:

...
Wenn man genau drüber nachdenkt, kann man aber dennoch OTP-Secrets irgendwie generieren, ohne sie speichern zu müssen. ...

Zum Vergrößern anklicken....

sag ich doch die ganze Zeit, aber wenn der Server über
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) , wahrscheinlich auch bei TOTP,
trotzdem das K und evtl. auch noch C speichern, dann nutzen mathematische Modelle nichts.

Ich hätte zu Beginn nicht erwartet, dass K ständig auf dem Server gespeichert bleibt.

Naja K muss es ja grundsätzlich vorhanden sein. C musst du natürlich bei HOTP auf dem Server speichern. Ohne Hardware-Token ist das außerdem kaum gut nutzbar. Habe das mal getestet: Paar mal zu oft auf den Token gekommen und der Mist fängt an.

Mathematisch wird es bei K schwierig, ja, aber man kann es eben durch Daten anreichern, die nicht zum Benutzer gespeichert sind.
Das macht es jedenfalls deutlich aufwändiger, mit einer geklauten Datenbasis etwas anzufangen. Hier ist dann wohl nur "Security by obscurity" möglich.

K muss grundsätzlich auf dem Server und dem Client zu Beginn gleich sein, kann aber dann nach der Initialisierung vom Server gelöscht werden, so das mathematische Modell, denn es gilt:

OTPn=Hn(concat(z,K)), OTPn entspricht 1. initiales OTP auf Server und Client gespeichert, Hn bedeutet z.B. kryptographische Hash-Funktion SHA-3 n-mal anwenden, n: z.B. 1 Mio., z: echte Zufallszahl, K: gemeinsames Kennwort.

jetzt kann z,K vom Server gelöscht werden.

Der Client erzeugt nun OTPn-m=Hn-m(concat(z,K)) mit dem zuvor vereinbarten z und K und der Server verifiziert einfach nur mit Hm(OTPn-m) und vergleicht mit den gespeicherten OTPn.
m: Anzahl der bei TOTP vergangenen z.B. 30s, bei HOTP ist normalerweise wohl m=1 je nach Abruf und n wird jeweils um 1 vermindert.
usw., bei mehreren nutzlosen Abrufen a ist bei HOTP m=a.

Grundsätzlich verstehe ich es, aber was genau ist OTPn jetzt? Das ist doch der Hash aus Hn(concat(z,K)).
Wie machst du dann OTPn - 30 ? Du brauchst aufm dem Server doch dann wieder z und K.