😀 mimimi
Ist doch ein schönes Abschiedslied.
Supporter
Anmeldungsdatum: Beiträge: 53484 Wohnort: Berlin |
|
Anmeldungsdatum: Beiträge: 6648 Wohnort: Technische Republik |
Ich habe das Problem auf Ubuntu-Mate 18.04. Danke dir trotzdem. ☺ |
Anmeldungsdatum: Beiträge: 4101 |
Eigenartig, auf dem Laptop habe ich mit Wire überhaupt kein Problem (weder jetzt noch in der Vergangenheit, und auch über diverse Betriebssysteme hinweg). Nur bei manchem Smartphones läuft es halt nicht ganz rund, aber das liegt wie bereits geschrieben an den restriktiven Einstellungen der Smartphonehersteller.
Dieses "mimimi" ist IMHO ein Verstoß gegen die DSGVO sein - und kann damit recht teuer werden. Vom Eingriff in die Privatsphäre durch Sammlung von Metadaten mal abgesehen… |
Anmeldungsdatum: Beiträge: 659 Wohnort: Lausitz + Honshu |
Ich rate davon ab, all-in-one-Lösungen zu benutzen. Damit sperrt man sich nur ein UND man muss alle anderen Teilnehmer dazu bewegen, diese Lösung auch zu nutzen. Für Text ist weiterhin E-Mail einfach das beste Mittel, denn es ist am weitesten verbreitet, auch wirklich end-to-end-verschlüsselt möglich (wenn man will) und das versenden von nicht-live-Dateien ist damit ebenfalls möglich (Bilder, Audio, Video). Für Audio-Video-live sollte man einfach SIP benutzen. Sync geht bei E-Mail sowieso, man kann auch seine ganzen Daten selber mit rsync synchron halten. Die IDs für die Dienste werden mittels vCARD verwaltet, da kann man gleich auch anderes syncronisieren. So wäre man wirklich unabhängig von irgendelchen Insellösungen und Konzernen, die sich alle abschotten, und hätte auf lange sicht einfach seine Ruhe davor, immer wieder auf was neues migrieren zu müssen. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 594 |
Das Setup halte ich für meinen Fall (B2C) für outdated. Die Email Kommunikation wird zu unübersichtlich. Außerdem ist der Kunde für das Management der Anhänge selbst verantwortlich, was wiederum einen Aufwand für ihn darstellt. Ein Bild oder ein Video zu verschicken ist zu viel Aufwand. Mit einer All-In-One Lösung sind viele Probleme beseitigt. Die Kommunikation bleibt übersichtlich (durch Suchfunktion innerhalb des Chats) und die Anhänge können schnell verschickt werden. Nicht umsonst hat WhatsApp und Co. die Email und SMS im privaten Bereich fast komplett abgelöst. Es ist einfach komfortabel. Also, als kleines Fazit ziehe ich:
|
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Dazu reicht es, den lokal gebildeten Hash zu übertragen. Wire überträgt aber das Passwort im Klartext zum Server (wenn auch per TLS), der es dort erst hasht, um es mit dem gespeicherten Hash zu vergleichen. Laut des verlinkten Reviews machen das zwar viele Webanbieter so, Wire als alleiniger Herr über Software und Protokoll wird dort aber in der Verantwortung gesehen, es besser zu machen:
Anders gesagt, „war schon immer so“ und „macht doch jeder“ sind einfach keine akzeptablen Entschuldigungen für unnötige Datenlecks. |
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Und vor allem inzwischen weit verbreitet. Viele spätere Nutzer kommen bei Messengern simpel und einfach hinzu, wenn genügend Leute Ihres Umfeldes dort schon sind. Diesen Effekt der kritischen Masse habt Ihr aber nicht bei Eurer eigenen Lösung für Eure Kunden. Außerdem sollte für Euch neben der Bequemlichkeit (die sich eh durch Eure Vorarbeit für die Kunden relativiert) auch die Datensicherheit Eurer Kunden wichtig sein. Da wäre für mich persönlich z.B. jeder US-basierte Dienst aus den zuvor genannten Gründen raus. Wenn Ihr es Euch zutraut, stellt Ihr idealerweise die Server selbst und überlasst deren Sicherheit und Datenschutz nicht irgendwelchen Dritten. Riesige Datenlecks bei Cloud-Hostern etc. gab es ja nun schon oft genug.
… neben RetroShare. Es wäre eventuell mal einen praktischen Test wert, um nicht eventuell eine gute Lösung aus einem Bauchgefühl heraus sausen zu lassen. Die meisten Reviews auf SourceForge und Alternative.to wirken nicht schlecht, die Code Frequency auf Github auch nicht, soweit ich das als Nicht-Programmierer beurteilen kann. Die letzten Pull Requests kamen in diesem Monat rein. Ich bin auf keine Art mit RetroShare verbunden, recherchiere nur gerne im Web. 🤓 |
Anmeldungsdatum: Beiträge: 4101 |
Ich glaube du hast da gerade einen kleinen Denkfehler. Wenn ich nur den Hash übertragen bräuchte, bräuchte ein Angreifer auch nur den Hash um an dein Konto zu kommen - etwa durch einen Datenbankleak. Ich muss bei diesem Anmeldeverfahren das Passwort übertragen, dass dieses gehasht wird dient rein dazu, dass in der Datenbank keine Klartextpasswörter stehen. Außerdem verwenden gute Hashverfahren Salts, und diese sind i.d.R. nur auf dem Server gespeichert, der Client weiß davon nichts. Abgesehen davon weiß auch nur der Server wie oft ein Hashverfahren (wie viele Runden) angewendet werden müssen (um Brute-Force zu erschweren), und erlaubt auch bspw. ein Upgrade des Hashverfahrens während des Logins ☺ Kurzum: Wenn es keine App-Tokens oder ähnliches gibt, muss ich das Passwort an den Server übertragen, damit dieser das Passwort verifizieren kann.
Nun, da kann ich nur zustimmen, irgendein anderes Verfahren wäre zu bevorzugen. Aber ich würde das aktuell verwendete Verfahren jetzt nicht als unnötig unsicher ansehen. Der einzig große Nachteil den ich sehe ist, dass das Passwort geändert werden muss, wenn ein Gerät kompromittiert wurde. Bei App-Tokens o.ä. kann ich einfach das Gerät kicken und fertig.
Ein unnötiges Datenleck sehe ich hier nicht wirklich, da es das Aufbrechen der mittels TLS verschlüsselten Verbindung erfordern würde. Das kann man relativ gut verhindern indem man das Zertifikat bzw. die Zertifikatkette prüft, falls nötig entsprechend im Quellcode verankert. Das kann man natürlich, wenn man ein Angreifer ist, auch wieder herauspatchen (diverses Schlangenöl machts das bspw. bei Browsern, Firefox versucht das Problem gerade zu lösen), aber das ist dann auf Clientseite ein Problem. Und wenn ich Zugriff auf den Server habe hilft mir auch ein besseres Verfahren nicht wirklich. Edit: Ich bin mir gerade nicht 100% sicher ob Wire nicht doch eine Art App-Token verwendet. Wenn ich mich einlogge kann ich meine Geräte auch managen und ich kann einzelne Geräte kicken. Das ist eig. schon immer so, zumindest so lange ich Wire verwende, was jetzt langsam über zwei Jahre werden. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 594 |
Von den Features her sieht Retroshare ziemlich gut. Aber: "Sehr geehrter Kunde, aktivieren Sie zuerst in den Android Einstellungen "unbekannte Quellen", installieren sich dann F-Droid und aus F-Droid wieder retroshare. Ach, Sie haben ein iPhone.... Mhh... Für iOS wir auf absehbare Zeit keine Lösung angeboten."
Da stimme ich dir grundsätzlich auch zu. Deshalb sind ja für mich Whatsapp und Telegram keine Lösungen. Aber, wenn man es perfekt machen möchte, sind viele Einbußen beim Komfort gefragt. Wire sieht für mich gerade wie ein guter Kompromiss aus. Und hostet nicht unsere Regierung auch ein paar Projekte bei Amazon? Und, wenn ich es pefekt machen möchte, dann bedeutet das bei der Buchhaltung auch GnuCash und LibreOffice anstatt z.B. sevDesk. Auf der anderen Seite, ich kenne Dienstleister im Gesundheitsbereich, die ihre Termine bei Google oder Apple liegen haben und die Rechnungen mit Google Docs geschrieben werden. Das ist für mich ein NoGo, weshalb ich dafür wahrscheinlich nextcloud einsetzen werde. |
Anmeldungsdatum: Beiträge: 2758 |
ich nehmen an, Signal wurde schon getestet und verworfen? Video/Telefonkonferenzen gehen meines Wissens nach nicht, und wie gut die syncronisation zwischen Desktop und mobilem Clienten funktioniert weiß ich nicht. Der Rest funktioniert aber gut. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 594 |
Signal ist auch nicht schlecht. Der Sync funktioniert sogar ganz gut. "Störend" finde ich es, dass man sich nur mit Telefonummer anmelden kann und auch nur darüber gefunden werden kann. Schöner wäre per Username z.B. "@timbolino". So muss ich auch nicht all meine Kontakte der App zur Verfügung stellen. |
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Mir fehlt das technische Wissen, um alle Details exakt einschätzen zu können, aber zu diesem Punkt wäre ein auf dem Client aus dem Passwort generierter Hash, der dann anstelle des Passworts übertragen wird und dann nocheinmal gehasht wird, eine Möglichkeit, Dein Angriffsszenario zu verhindern und trotzdem das Passwort nicht dem Server und allen auf ihn entsprechenden Zugriff habenden Personen zu verraten.
Ich folge da eher der verlinkten Kritik, dass Wire es relativ leicht sicherer machen könnte. Die nötigen Verfahren gibt es seit vielen Jahren, müssen also nicht von grundauf neu erfunden werden, und Wire hat die volle Kontrolle über Server und Client. Das entspricht exakt meiner Definition von „unnötig unsicher“, insbesondere bei einem Produkt, bei dem Sicherheit einer der zentralen Aspekte ist.
Es bleibt jedweder andere Zugriff auf die Server von den Betreibern, Hackern oder Behörden. Die bekämen zwar dann eine Menge weiterer Daten, aber eben nicht das Passwort, und nur um diesen Teilaspekt geht es hier.
Wenn App-Unterstützung für Eure Kunden wichtig ist, verstehe ich Eure Entscheidung gegen RS natürlich vollkommen. Die fehlende iOS-Unterstützung finde ich persönlich besonders schade, da meine Freundin ein iPhone hat. 😕 (Ich selbst habe gar kein Smartphone, deswegen ist mir ansonsten deren fehlende Unterstützung egal.)
Dass es andere auch nicht besser machen sollte kein Kriterium für das eigene Handeln sein. Ich stimme Dir insofern vollkommen zu, dass ich es seit jeher für ein Unding halte, dass deutsche Behörden und Unternehmen die Daten ihrer Bürger und Kunden ausländischen Datenkraken und Geheimdiensten frei haus liefern. Ähnlich kritisch sehe ich die flächendeckende Nutzung und daraus resulterende Abhängigkeit von Windows in hiesigen öffentlichen Institutionen (ich arbeite selbst in einer).
Viel Erfolg und sieh bitte meine Beiträge als konstruktive Kritik auf dem Weg zu einer für Euch besten Lösung, inklusive dem einen oder anderen Kompromiss. 😉 |
Anmeldungsdatum: Beiträge: 4101 |
Im Prinzip hast du dann das Problem, dass der Hash, der aus dem Passwort berechnet werden kann, genauso funktioniert wie vorher das Passwort. Das Problem wird also nur verschoben, aber nicht gelöst. Der einzige Vorteil wäre, dass dein eigentliches Passwort nicht ganz so einfach in andere Hände gelangen kann, weil es nie dein Gerät verlässt. Muss es aber eben auch nicht, weil der Hashwert dann vollkommen ausreicht. Besser wäre dann gleich App-Passwörter o.ä. zu verwenden. D.h. ich melde mich einmalig von einem Gerät aus an, eröffne eine neue Session (mit eigenem, zufällig generiertem Passwort/Token), und muss dann auf diesem Gerät nie wieder das Passwort benutzen. Das sollte natürlich transparent im Hintergrund passieren (Mastodon macht das bspw. so). Das Passwort muss auf dem Gerät auch nie gespeichert, und auch nur einmalig übertragen werden, da jede weitere Nutzung dann mit dem App-Passwort erfolgt. Außerdem kann ich dann – vom Server aus – jederzeit den Zugriff einzelner Geräte deaktivieren.
Gut, ob es Sinn macht, über diesen Teilaspekt zu diskutieren während man Vollzugriff auf den/die Server hat, halte ich für fraglich. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 594 |
Das ganze Leben ist doch ein Kompromiss. Bin jedenfalls für all eure Beiträge dankbar! |
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Sorry für die späte Antwort, ich hatte die Benachrichtigung übersehen. 😇
Warum wurden Hashes dann überhaupt eingeführt? Und spricht der Grund dafür nicht genauso gegen ein Bekanntwerden der eigentlichen Passwörter auf Seiten der Server? (Ernsthafte Neugier, denn ich verstehe bislang nicht, warum Letzteres egal sein soll, Hashes aber bestimmt nicht grundlos erfunden wurden.) |