Dropbox erzwingt neue Passwörter

error

Lt. Commander
Registriert
Aug. 2007
Beiträge
1.306
Moin zusammen,

Dropbox ist aktuell dabei Nutzer mit alten Passwörtern (2012 und älter) zu zwingen diese zu ändern, da diese evtl. 2012 (gehasht und gesalzen) entwendet wurden.
Reagieren sie aber schnell.....

E-Mail:
Hallo X. Y,

falls Sie Ihr Dropbox-Kennwort seit Mitte 2012 nicht geändert haben, werden Sie bei Ihrer nächsten Anmeldung dazu aufgefordert. Dies ist eine rein präventive Maßnahme – wir danken Ihnen für Ihre Mithilfe.

Weitere Infos zu dieser Vorsichtsmaßnahme finden Sie auf dieser Seite in unserem Hilfecenter. Bei Fragen wenden Sie sich bitte an password-reset-help@dropbox.com.

Vielen Dank!
Das Dropbox-Team

FAQ:
https://www.dropbox.com/help/9257

Gruß
 
ist doch gut, alle 5 Jahre mal ändern schadet nicht,
zumal Dropbox wahrscheinlich etwas geändert hat, gut gut !
 
@piepenkorn: Ich dachte es interessiert jemanden :D

@engine: Nur alle 5 Jahre? Dropbox hat vermutlich die Userdaten mit dem Leak abgeglichen und vorsorglich alle angeschreiben.
 
error schrieb:
@engine: Nur alle 5 Jahre? Dropbox hat vermutlich die Userdaten mit dem Leak abgeglichen und vorsorglich alle angeschreiben.

"vermutlich" ist Spekulation ;)

Es könnte sich auch einfach die Art der Speicherung von Passwörtern geändert haben, was eine neue Angabe von Passwörtern nötig macht. Dafür spricht auch, dass von Mitte 2012 gesprochen wird. Möglich, dass ab der Zeit schon Passwörter anders gespeichert werden und man nun die alten Methoden komplett beseitigen möchte ;)

Außerdem war laut Dropbox-Mail auch nicht wirklich viel Zugzwang für die User dahinter. Es hieß ja "werden Sie bei Ihrer nächsten Anmeldung dazu aufgefordert", was für mich soviel heißt wie "machen Sie mal, wenn Sie Zeit haben" ;)

Mir ist das allemal symphatischer als "Wir haben Ihr altes Passwort mal in unser neues Format übernommen" :D
Und 2012 ist nun auch schon eine Ecke her. Gelegentlich ist es schon sinnvoll, seine Passwörter zu aktualisieren :D
 
Trotzdem eine sehr merkwürdige Sache. Habe die Mail auch bekommen, aber habe auf dem Account das PW nach 2012 geändert. Das war u.a. 2013 und 2014. (Kann ich über den Verlauf im PW-Manager nachvollziehen.)
 
Darum steht da ja auch "falls Sie Ihr Dropbox-Kennwort seit Mitte 2012 nicht geändert haben, werden Sie bei Ihrer nächsten Anmeldung dazu aufgefordert.".
 
Ich habe eine zweistufige Überprüfung und zudem ist es mir egal, habe nichts wichtiges auf Dropbox.
Trotzdem ist es stümperhaft von Dropbox, denn wenn man schon etwas anbietet, dann sollte man schon wissen, was man tut.

Ich wurde jedenfalls nicht aufgefordert mein PW zu ändern, obwohl ich auch die Mail bekam.

Was mir sorgen macht, Telekom hat keine zweistufige Überprüfung, dort habe ich aber wichtiges verschlüsselt, trotzdem macht mich die Cloud-Geschichte grundsätzlich immer nervöser.
Bis auf weiteres lösche ich alles Teile und schleppe halt einen USB-Stick mit mir herum, wie damals.
 
Zuletzt bearbeitet:
Das Problem ist aber, dass die 2FA bei Dropbox nichts nützt, wenn auch die 2FA-Secrets gestohlen werden.
Sicherer kannst du die Cloud machen, in dem du deine Daten einfach vorher in einen Truecrypt/Veracrypt Container packst ;)
 
Es reicht ein Hack da, wo Dropbox die Secrets der User speichert, ähnlich wie es auch bei Passwörtern passiert.
 
Wir reden über 2FA-OTP über eine Auth.-app, also ohne SMS.
Das Generieren der OTP von der Initialisierung (QR-Code) bis zur Verifizierung auf dem Server ist mathematisch korrekt.
Server und Client haben zunächst ein gemeinsames gespeichertes initiales OTP, erzeugt durch mehrmaliges anwenden einer Hashfunktion H auf eine Zufallszahl kombiniert mit einem gemeinsamen geheimen Kennwort.
Der Server verifiziert das vom Client gesendete neue OTP (PIN laut Auth.-app) durch die einmalige Anwendung der Hashfunktion H auf dasselbe OTP vom Client und vergleicht es mit seinem zuletzt gespeicherten OTP.
Der Server muss also keine zukünftig korrekten OTP speichern, sondern nur das aktuell verwendete, alles geht also vom Client (Smartphone-Auth.-app) aus.
Da die Hashfunktion H nicht umkehrbar ist, kann nicht vom auf dem Server gespeicherten OTP auf das nächste vom Client zu sendende OTP geschlossen werden.
 
Mir ist bewusst, wie TOTP funktioniert ;) Du vergisst hier aber, dass Dropbox das Secret benötigt, mit dem er das Vergleichs-OTP erzeugt. Woher bekommt er das Secret? Genau... es wird initial gespeichert! ;)
 
Zuletzt bearbeitet:
Nein, das funktioniert so nicht, es wird immer nur das aktuelle OTP vom Client auf dem Server gespeichert.
Das Verfahren ist mathematisch so ausgelegt, dass es funktioniert. Ich könnte es erklären, aber du musst mir schon glauben. Nur das hier: H((OTPn-1)client)=OTPn_auf_Server_gespeichert, auf dem Server wird jetzt (OTPn-1)client gespeichert. Wenn n-1 Null wird, erfolgt eine neue Initialisierung.

Alles Vergangene wird vom Server vergessen, auch die Initialisierung, wird nicht benötigt, das steckt alles im Synchronen Status von Client/Server und der Hashfunktion und dem initialen OTP, alles weitere baut auf diesem initialen OTP auf.

Aber es gibt trotzdem Angriffsmöglichkeiten, die aber nicht im 2FA liegen, sondern einfach im Aufbau einer Fake-Seite, aber das ist ein anderes Thema.
 
Nein, weisst du nicht, sonst wuerde 2FA ja absolut keine zusaetliche Sicherheit bieten. Es ist ja genau die Idee an der ganzen Geschichte, dass nur du das Secret hast.

Lass es mich erklaeren wie das trotzdem funktioniert (zumindest eine Moeglichkeit).

Nennen wir deinen PC 'Client' und Dropbox 'Server'. Der Client generiert/besitzt ein geheimes Secret, welches nur der Client selbst weiss. Dieses Secret verlaesst idealerweise nie den PC. Jetzt wenden wir eine ggf. oeffentliche aber vorallem unumkehrbare Hashfunktion auf dieses Secret (N) mal an und schicken das Ergebnis an den Server. Beim ersten Login Versuch schickt der Client nun das Ergebnis der Hashfunktion (N-1) mal angewendet auf das geheime Secret. Der Server kann mit einer einmaligen Anwendung der Hashfunktion ueberpruefen, ob es mit dem gespeicherten Wert uebereinstimmt. Ander herum kann der Server aber nie selbst den (N-1)ten Funktionswert generieren, da die Hashfunktion ja unumkehrbar ist. Zukuenftige Logins benutzten dann den Wert von N-2, N-3 etc...Der Server muss sich also nur merken wie oft er die Hashfunktion anwenden muss (also einfach mitzaehlen) oder (effizienter) einfach seinen Speicher mit dem vorherigen Wert updaten. Alles klar soweit?
 
Danke ihr beiden ;)

Ok, dann bin ich von der TOTP-Methode ausgegangen, bei der auf ein Secret der aktuelle Unix-Timestamp per HMAC angewendet wird und sich daraus das OTP errechnet.

Aber, ihr schreibt, dass der Client ja die Anzahl der Anwendungen kennen muss, also N-1, N-2 usw., dass bedeutet doch, dass der Client einen Counter benötigt, das HOTP entspricht. Beim Dropbox wird aber definitiv alle 30 Sek. ein neues OTP generiert.
Außerdem gibt man beim Login ja nur das OTP, also die 6 stellige Zahl an. Wie kommt man dann auf N-n? Wie spielt der Unix-Timestamp da mit? Hat das von euch genannte Verfahren eine genaue Bezeichnung?
 
Das ist ne simple Hashchain, findest du sicher auf Wikipedia.
Deine Fragen versteh ich nicht ganz. Du kannst doch einfach den Nten Funktionswert von der Zeit abhängig berechnen...und der Server eben auch zeitlich synchronisiert den Nten Funktionswert erwarten. Wie das Dropbox genau macht weiss ich nicht. Aber da gibts sicher einen Standard.

Aber ob das jetzt 6 Stellig oder was auch immer ist, ist doch egal, du kannst alles immer noch hashen/abschneiden was auch immer damit du auf 'User zumutbare' Codes kommst.
 
Das obige Berechnungsverfahren ist jedenfalls für 2FA-OTP's üblich.
Und das nur der Client (Smartphone-app) das Login-OTP generiert ist auch klar,
denn die OTP's funktionieren auch ohne Internet-Verbindung, also offline.
Die Zeit muss auch synchron mit dem Server sein für TOTP, verstelle mal die Uhrzeit auf dem Smartphone, dann funktioniert keinen Login.
Und üblich ist TOTP. Wenn die Hashfunktion 1 Mio. mal* auf die Initialisierung angewendet wird bei 30 Sek. pro OTP, dann muss nach ca. 11 Monaten reinitialisiert werden.
Das TOTP-Verfahren geht je nach Implementierung stark an die Batteriestandzeit.

Reines Gedankenbeispiel, da ich nicht weiß wie Dropbox und OTP Auth app das machen.
 
Zuletzt bearbeitet:
M@C schrieb:
Das ist ne simple Hashchain, findest du sicher auf Wikipedia

Besten Dank :) Dazu finde ich einiges :)

M@C schrieb:
Aber ob das jetzt 6 Stellig oder was auch immer ist, ist doch egal, du kannst alles immer noch hashen/abschneiden was auch immer damit du auf 'User zumutbare' Codes kommst.

Gut, das muss dennoch ein Standardweg sein, denn die Google Authenticator App "kennt" diesen Weg ja.


engine schrieb:
Die Zeit muss auch synchron mit dem Server sein für TOTP, verstelle mal die Uhrzeit auf dem Smartphone, dann funktioniert keinen Login.

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

Ich haben hier mal den Sourcecode gefunden: https://github.com/google/google-authenticator
Das unterstützte Verfahren ist hier HOTP oder TOTP (https://tools.ietf.org/html/rfc6238#section-4.1)
Es sieht mir hier daher nicht so aus, dass hier mit einem Weg gearbeitet wird, den ihr genannt habt, jedenfalls wäre mir dann nicht klar, wie Dropbox ohne das Secret auf das richtige 6-stelligen-OTP kommen kann, nur anhand des eingegebenen OTP's.
 
Zuletzt bearbeitet:
Zurück
Oben