Dropbox erwirbt Boxcryptor-Technologie
von caschy | 24 Kommentare
Klingt fast nach einem deutschen Märchen. Zumindest für die, die ihr Wissen zu Geld machen konnten. Dropbox hat mitgeteilt, eine Vereinbarung zur Übernahme mehrerer wichtiger Assets von Boxcryptor, dem deutschen Anbieter von Ende-zu-Ende-Verschlüsselung mit „Zero-Knowledge“ für Cloud-Speicherdienste, unterzeichnet zu haben. Die Kombination der Verschlüsselungsfunktionen von Boxcryptor und des nutzerfreundlichen Produkts Dropbox soll dazu beitragen, die steigenden Anforderungen der Kunden noch besser zu erfüllen. Es sollen wichtige Funktionen von Boxcryptor nativ in die kostenpflichtigen Tarife von Dropbox für Geschäftskunden eingebunden werden. Indem Dateien lokal auf den Geräten verschlüsselt werden, bevor sie mit Dropbox synchronisieren, wird eine zusätzliche Sicherheitsebene geschaffen.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Kann man nur hoffen das Boxcryptor als eigenständiges Produkt nicht eingestellt wird. Ich nutze es nämlich für diverse andere Dienste.
Auf der Boxcryptor ist ein wenig mehr darüber zu lesen. Neukunden nehmen sie nicht mehr an. Also ist am Ende der Vertragslaufzeit Ende. Schade. Gibt es Alternativen? Mit Cryptomator werd ich noch nicht so richtig warm.
Schau dir Cryptomator an: https://cryptomator.org
Macht dasselbe, aber als Open Source und mit Unterstützung von mehr Plattformen.
Oh Mann, ich sollte Lotto spielen. Gerade eine 3-Jahres-Lizenz von BC erworben, bin mal gespannt, wir es weiter geht.
Cryptomator war in meinen Tests übrigens keine adäquate Alternative. Windows-Suche wird nicht unterstützt, die Performance war ziemlich schlecht und unter Windows spielte Groß/Kleinschreibung von Dateinamen plötzlich eine Rolle. Alles irgendwie nicht rund.
Schade, dass man die Kunden nicht zeitgleich informiert.
Leider ist genau das jetzt geschehen 🙁
Ich bin auch verzweifelt, da ich keine gute Alternative zu BC kenne.
„eine Vereinbarung zur Übernahme mehrerer wichtiger Assets“
Also keine Übernahme der deutschen Firma, sondern eine Art „Lizenzierung von Technik / Patenten“?
„Es sollen wichtige Funktionen von Boxcryptor nativ in die kostenpflichtigen Tarife von Dropbox für Geschäftskunden eingebunden werden.“
Die Frage wäre da: sollen auch die *Funktionen* (Routinen) von Boxcryptor in den Dropbox-Client eingebaut werden?
Wenn ja, dann wäre im Programm eines US-Anbieters – dem man nicht vertraut bzw. dessen Heimatstaat man nicht vertraut – die Routinen, welche die Verschlüsselung übernehmen …. und somit auch die Schlüssel kennen …. und auf Anforderung dann vlt. in die USA zu den Behörden geben müssen….?
Hääää? Welche Schlüssel kennen die? Lass Dir besser noch einmal die Funktionsweise von BC und die Begriffe „Ende-zu-Ende-Verschlüsselung“ und „Zero-Knowledge“ erklären
Johann hat natürlich Recht, was die Funktionsweise von Boxcryptor bzw e2ee angeht. Allerdings ist Boxcryptor nicht quelloffen, was sie mMn von vornherein disqualifiziert, siehe zum Beispiel https://www.boxcryptor.com/en/blog/post/cryptomator-check-cloud-encryption/.
Da ändert eine wie auch immer geartete Übernahme durch Dropbox auch nichts mehr dran.
„Allerdings ist Boxcryptor nicht quelloffen, was sie mMn von vornherein disqualifizier“
Solche Sätze lese ich ziemlich oft. Und mir scheint, dass da einfach Gedanken von anderen übernommen werden, ohne sie zu hinterfragen.
Quelloffen bedeutet nicht automatisch sicher und nicht gut. Ich habe in meinem Archiv mehrere Beispiele von Sicherheitslücken in Open Source, die jahrelang nicht entdeckt wurden. Beispiele: eine 15 Jahre alte Sicherheitslücke in Python, eine Schwachstelle in der häufig genutzten zlib (17 Jahre alt). Machen wir weiter mit der Lücke in Polkit, auch eine wichtige und vor allem sicherheitsrelevante Linux Komponente – Lücke seit Anfang an (2009). Log4j ein weiteres Beispiel. Es gibt noch viel mehr.
Der Satz ist also offensichtlich quatsch. Nimm noch dazu die Vorfälle von Repository Poisening – Quellcode in Bibliotheken der heimlich über unscheinbare Commits eingebaut wird.
Ein kleines Stück hast du Recht: Open Source bietet wenigstens die Chance den Code zu durchforsten. Aber es muss jemand tun. Und es muss jemand tun, der Ahnung hat. Kannst du Code lesen und beurteilen? Prüfst du Software im Quellcode, bevor du sie einsetzt? Oder vertraust du prinzipiell Open Source?
Menschen die als Programmierer sehr gutes Geld verdienen, dazu zu bringen, ehrenamtlich in Open Source Projekten zu arbeiten, ist offensichtlich schwierig. Daher fehlt vielen tollen Projekten einfach die Man- oder Womanpower.
Für mich ist daher entscheidender, ob ich die Software von Leuten gemacht wird, die Ahnung von der Materie und Sicherheit im Fokus haben. Und das sehe ich bei Boxcryptor schon. Open Source bevorzuge ich, aber ein Ausschlusskriterium ist das wirklich nicht.
>Kannst du Code lesen und beurteilen?
Ja und ja.
>Prüfst du Software im Quellcode, bevor du sie einsetzt?
Ja.
>Oder vertraust du prinzipiell Open Source?
Nein, siehe vorherige Antworten.
>Menschen die als Programmierer sehr gutes Geld verdienen
Bin ich.
>ob […] die Software von Leuten gemacht wird, die Ahnung von der Materie und Sicherheit im Fokus haben.
Des Pudels Kern. Wie soll ich das beurteilen, wenn ich den Code nicht sehen kann?
>Und das sehe ich bei Boxcryptor schon
Woran genau? Klar, sie veranlassen Audits usw, aber letztendlich gilt wie immer „Show me the code“.
Liest und verstehst Du den Code von sämtlicher OSS die Du einsetzt? Wie lange hast Du für zu. B. für Vaultwarden oder den Linuxkernel gebraucht? Hast Du Sicherheitslücken gefunden und gemeldet? Bekommst Du die Zeit dafür bezahlt oder ist das ein Hobby?
Lesen und Verstehen des Codes ist aber nicht alles! Dazu kommt noch ein Verstehen des Entwicklungs- (inkl. der Fallstricke – sprich Angriffspunkte) sowie des Anwendungszweckes (und da nicht nur des eigenen, sondern auch der ursprünglichen bzw. aller Entwickler, die daran gearbeitet haben). Das kann viel aussagen welche Probleme auftreten können…
Wie ich schon schrieb: „Open Source bietet wenigstens die Chance den Code zu durchforsten. Aber es muss jemand tun.“
Ich habe mich nur dagegen gewandt, dass so unglaublich viele Menschen denken, dass Open Source prinzipiell sicher und vertrauenswürdig ist. Und das ist definitiv nicht so.
Natürlich hast du recht, dass es ohne Einblick in den Quellcode gar keine Chance gibt, die Qualität zu beurteilen. Aber der Aufwand ist so groß und wird durch die Verwendung von externen Bibliotheken immer größer, so dass die reale Kontrolle eher hypothetisch ist.
Ich kann mir nicht vorstellen, dass von den wenigen Menschen, die Quellcode lesen und verstehen können, auch noch genügend dabei sind, die das Wissen haben den Quellcode so genau lesen zu können, um Lücken und Hintertüren zu entdecken, Und wie viele Menschen haben die unglaublich Zeit wie du, den Quellcode zu lesen. Und wer kontrolliert den Quellcode der verwendeten Bibliotheken noch dazu? Wenn man das erst meint, dauert das auch für gute Programmierer Tage. Sei ehrlich: Es scheint ein Hobby von dir zu sein, aber wer hat diese Zeit?
Ich will nur, dass die Leute darüber nachdenken, dass Open Source eben nicht automatisch gut ist. Selbst wenn das Team super Arbeit leistet, kann die Lücke und der Datenabfluss in einer verwendeten Bibliothek oder in einem SDK stecken.
Grundsätzlich hast du recht, allerdings ist es nunmal unter US-Recht deutlich wahrscheinlicher, dass Dropbox zu irgendwas gezwungen wird, was bei Open Source zumindest auffälliger wäre. Natürlich kompilieren sich die wenigsten Cryptomator selbst oder checken den Quellcode. Dropbox an sich ist auch einfach wesentlich komplexer, unübersichtlicher und auch nicht unbedingt für gute Designentscheidungen bekannt. Am Ende bleibt es aber mehr eine Einschätzung nach Bauchgefühl.
„Quelloffen bedeutet nicht automatisch sicher und nicht gut.“ Das hat Horst gar nicht behauptet, seine Aussage war „*nicht* quelloffen ist automatisch schlechter“. Die beiden Aussagen stellen keine Dichotomie dar, deine Beispiele zu Sicherheitslücken in Open Source treffen alle genau so auf Closed Source zu.
+100
Mein Reden seit Anno Tobak.
Was nützt Ende-zu-Ende-Verschlüsselung wenn man dem Client (!) nicht trauen kann?
Vielleicht solltest du mal schauen, was Asset bedeutet.
Sehr sehr schade! Nutze Boxcryptor seit Jahren und war immer sehr zufrieden. Natürlich toll für die Entwickler
Gehört Dropbox nicht zu jenen Unternehmen, die laut Snowden ein Wunschpartner für das allumfassende Überwachungsprogramm Prism der Geheimdienste von USA, GB, Kanada, Australien und Neuseeland war?
Und seit Snowden wissen wir, das US Firmen – ob sie wollen oder nicht – immer im Zugriff ihrer Geheimdienste (und auch Behörden) stehen.
Für wirklich sensible Daten – etwa als wichtige Firmen oder staatliche Institutionen – würde ich da kein Vertrauen haben (gewöhnliche Nutzer sind davon eher nicht betroffen, da sie ja nicht im Fokus dieser Dienste stehen).
Da hilft auch nicht Behauptung, diese Dienste würden im „Interesse des Guten“ handeln. Sie handeln am Ende immer im Interesse ihrer Staaten, nicht anders als chinesiche oder russische Geheimdienste – und ob da zeigt sich, dass das nicht immer das Gute war.
Als wenn ich es geahnt hätte, gestern noch die App von meinem iPhone gelöscht, da ich den Vertrags bereits gekündigt hatte und der ausläuft.
ich war mit BC lange Zeit zufrieden, aber in letzten Zeit kam da nicht mehr viel und nachdem ich mehrfach Probleme mit meinem Macbook hatte, der auf BC zurückzuführen war, hab ich mich davon komplett verabschiedet.
Na ja, was Boxcryptor anbietet, kann man mit EncFS selber basteln.
Nur eine App für Handys fehlt dann natürlich.
EncFS ist leider keine empfehlenswerte Lösung mehr. EncFS enthält uralte Sicherheitslücken die in Audits gefunden wurden. Ich würde daher eher Cryptomator oder Veracrypt einsetzen.
Verstehe ich das richtig, dass man Boxcryptor weiterhin lokal nutzen kann ohne ein registriertes Benutzerkonto? (Schlüsseldatei lokal abgespeichert)