Hallo, folgendes Problem: Es sollen für einen Verein Daten sicher per Netz verteilt werden. Die Empfänger sind z.T. weniger technikaffine Mitbürger, deshalb soll den Anwendern nicht mehr zugemutet werden wie Datei anklicken -> PW eingeben -> fertig. Problem könnte noch sein, dass unbekannt ist, welches Betriebssystem bei den einzelnen Empfängern genutzt wird. Mein Favorit wäre ja eine Art "selbstentpackender Veracrypt-Container" - aber das ist vermutlich utopisch. Ist ein verschlüsseltes Zip-File ausreichend sicher? Oder kennt jemand andere Lösungen. Danke. P.S: Die Daten werden öffentlich auf einem Server abgelegt und sind nicht hochgeheim, aber sollten auch nicht in wenigen Stunden/Tagen zu knacken sein.
Zumindest 7-Zip ermöglicht beim Zip-Archiv eine Verschlüsselung mit AES-256. Also ja: ist für deine Zwecke sicher genug. Das Problem ist dann doch wieder das Passwort zu verteilen, beziehungsweise sicher aufzubewahren. Viele Grüße.
Mit 7-Zip packen und verschlüsseln. https://www.7-zip.org - Strong AES-256 encryption in 7z and ZIP formats - Self-extracting capability for 7z format
Funktioniert ein selbstentpackendes 7-zip-Archiv auch unter Linux/Mac? P.S: PW-Weitergabe erfolgt vorher bzw. mündlich
MT schrieb: > > Mein Favorit wäre ja eine Art "selbstentpackender Veracrypt-Container" - > aber das ist vermutlich utopisch. Selbstentpackend ist ganz großer Murks und vor allem auch Böse. Begründung: 1. Die EXE die bei Windows funktioniert, wird bei Linux und Mac nicht funktionieren. 2. Selbst wenn du nur Windowsnutzer hast, wollen die von dir keine Viren die dann mit deiner EXE auf deren Rechner ausgeführt werden. 3. Selbstentpackende Archive lassen sich schlecht reparieren. Deswegen müssen Packprogramme rein passiv sein. Dann bleibt die Sicherheit beim Nutzer, da er sein Packprogramm von seriösen Quellen installieren kann und sich nicht auf seine Bekannte verlassen muss. > Ist ein verschlüsseltes Zip-File ausreichend sicher? Meines Wissens nach taugt die Verschlüsselung bei ZIP nichts. Ich habe aber mal 7z für so eine Aufgabe verwendet, das verwendet AES. Das Problem ist nur, das offizielle 7z scheint es für Mac nicht zu geben und die Laien kamen trotzdem nicht damit klar. Allerdings hatte ich ein Archiv, das auf mehrere kleine verteilt war. 7z kann das problemlos aufsplitten und beim Downloaden hilft das dann, aber wenn die Laien nicht alle Dateien downloaden, kann es nicht funktionieren. Das Problem vor dem Bildschirm wirst du also nicht loswerden. Eine Alternative zu 7z wäre noch RAR. Das kann auch AES und kann unter Win, Mac und Linux entpackt werden. Allerdings kann es sein, dass die freie RAR Version nur bis zu einer bestimmten RAR Formatversion entpacken kann. Das müsstest du noch einmal testen. Im Zweifelsfall würde ich 7z verwenden. > Oder kennt jemand andere Lösungen. Ne Cloud mit PW Funktion oder bei dem der Hash in der URL das PW ist. Sicherlich gibt's auch Clouddienste, bei dem man ein PW in der URL mit angeben kann. > P.S: Die Daten werden öffentlich auf einem Server abgelegt und sind > nicht hochgeheim, aber sollten auch nicht in wenigen Stunden/Tagen zu > knacken sein. Wenn es Fotos sind, dann Recht am eigenen Bild usw. beachten. Verschlüsseln ist daher immer besser. Sorg du dafür, dass du auf der sicheren Seite bist, auch wenn es für andere dann kompliziert sein mag. Insofern, nimm 7z. Veracrypt würde ich nicht nehmen, die Containerdateien passen sich ja nicht der Größe des Dateninhalts an.
Dennis S. schrieb: > Das Problem ist > dann doch wieder das Passwort zu verteilen, beziehungsweise sicher > aufzubewahren. > > Viele Grüße. Die 7z Dateien legt man auf eine Cloud, dann kann sich die Daten jeder genau dann runterholen wenn er sie braucht und man müllt damit auch nicht den E-Mail Account der anderen zu. Das PW kann man per E-Mail verschicken. Serverside Verschlüsserlung gibt's bei Klartext E-Mail ja durchaus. Und um an die Daten zu kommen, müsste derjenige auch wissen wo sie liegen. Ansonsten eben mit OpenPGP, aber das dürfte 97 % der Laien überfordern. Wenn es die Möglichkeit gibt, kann man das PW aber auch per Telefon verschicken. SMS ist schlecht, das könnte alles überwacht und mitgelesen werden. Gut sind dagegen wieder einige wenige Instant Messenger Protokolle, die Verschlüsselung dabei haben.
Nano schrieb: > Deswegen müssen Packprogramme rein passiv sein. Korrektur: Die Paketdateien müssen rein passiv sein. Das Programm selbst darf und muss natürlich aktiv sein, aber es ist nicht zum untereinander austauschen da. Getauscht werden sollten nur die passiven Paketdateien. *.7z, *.zip, *.rar ist also gut eine selbstausführendes *.exe mit Zip, 7z usw. Algorithmus ist böse.
Warum nicht auf einen Cloud Filedienst stellen und den Ordner per Passwort freigeben? Neben Dropbox, GDrive, Onedrive gibt es auch Tresorit, Sync.com, pCloud und andere, die mehr in Sicherheit investieren.
Nano schrieb: > Das PW kann man per E-Mail verschicken. Nano schrieb: > SMS ist schlecht, das könnte alles überwacht und mitgelesen werden. Haha, das ist wohl ziemlich widersprüchlich. dgfvlkjdf
MT schrieb: > Oder kennt jemand andere Lösungen. > > P.S: Die Daten werden öffentlich auf einem Server abgelegt und sind > nicht hochgeheim, aber sollten auch nicht in wenigen Stunden/Tagen zu > knacken sein. Eine Lösung wäre, dass die Daten per JavaScript direkt im Webbrowser der Benutzer entschlüsselt werden. Die Daten selbst liegen dann zwar verschlüsselt auf dem Server und werden auch verschlüsselt an die Client-Rechner übertragen, die Benutzer selbst merken von dieser Verschlüsselung aber gar nichts; für sie sieht es so aus, als hätten sie die Datei bereits entschlüsselt heruntergeladen. Das ist einerseits völlig betriebssystem-unabhängig, und grundsätzlich auch leichter: Die Benutzer müssen nicht erst ein entsprechendes Packprogramm via 7zip installieren und sich damit vertraut machen. Allerdings frage ich mich: Warum überhaupt die Datei öffentlich ablegen - und nicht stattdessen einfach dafür sorgen, dass die Datei eben nicht öffentlich ist, sondern erst nach vorheriger Autorisierung heruntergeladen werden kann? Das wäre doch die einfachste Lösung.
dgfvlkjdf schrieb: > Nano schrieb: >> Das PW kann man per E-Mail verschicken. > > Nano schrieb: >> SMS ist schlecht, das könnte alles überwacht und mitgelesen werden. > > Haha, das ist wohl ziemlich widersprüchlich. > > dgfvlkjdf Bei E-Mail gibt es noch, wie ich oben schon sagte, Serverseitige Verschlüsselung. Bei Geheimdiensten müsste der E-Mail Provider mitspielen, der kann aber auch im Ausland sitzen. Bei der SMS hast du definitiv alles im gleichen Land, solange du innerhalb Deutschland die SMS verteilst. Außerdem erwähnte ich noch OpenPGP. Wenn die Sicherheit also gewünscht ist, dann kann man die mit E-Mail haben. Mit SMS geht das nicht.
Nano schrieb: > Wenn es Fotos sind, dann Recht am eigenen Bild usw. beachten. > Verschlüsseln ist daher immer besser. Nicht nur, auch Vereinsdokumente Joachim S. schrieb: > MT schrieb: > Allerdings frage ich mich: Warum überhaupt die Datei öffentlich > ablegen "Firmenpolitik" :rolleyes: Wie gesagt: Passwort verteilen erfolgt vorab und mündlich
Den 7zip-Pfuschern würde ich in Sachen Krypto nicht mehr vertrauen. https://threadreaderapp.com/thread/1087848040583626753.html
MT schrieb: > Joachim S. schrieb: >> MT schrieb: >> Allerdings frage ich mich: Warum überhaupt die Datei öffentlich >> ablegen > "Firmenpolitik" :rolleyes: Kann es sein, dass da diesbezüglich bei den Verantwortlichen im Verein einfach ein Missverständnis vorliegt? Mir fällt jedenfalls auf Anhieb kein Grund ein, warum jemand bei Daten, die eben nicht öffentlich (sondern nur einem bestimmten Personenkreis) zugänglich sein sollen, unbedingt darauf bestehen sollte, dass sie öffentlich (wenn auch verschlüsselt) zugänglich sein sollen... Aber falls dem wirklich so ist: Clientseitige Entschlüsselung direkt im Webbrowser per JavaScript wäre die einfachste/benutzerfreundlichste Lösung. Wäre aber natürlich mit einem gewissen Entwicklungsaufwand verbunden.
Jemand schrieb: > würde ich in Sachen Krypto nicht mehr vertrauen. ZUfall ohne Zufall kommt von Fall zu Fall mal vor (seit Jahrzehnten). Es tauchen noch mehr Überlegungen auf. 1. Müssen alle User die gleichen Daten bekommen, 2. Müssen sie wieder Daten zurückliefern? 3. Müssen/dürfen diese Dateien eine begrenzte Haltbarkeit haben? 4. Man kann auch Daten auf verschiedene Orte verteilen... Split? 5. Manches wird erst recht interessant je geheimer es deklariert wurde.
MT schrieb: > Wie gesagt: Passwort verteilen erfolgt vorab und mündlich Dann verteile den Kram als Passwortgeschütztes .zip, das dürfte aktuell jedes Betrübssystem können, sogar Linux schon. Wenn mir jemand selbstextrahierende Files liefern will, frage ich den in sehr unfreundlichem Ton, was er sich dabei denkt.
Ich hätte Nextcloud auch noch ins Rennen geschickt. Grad Webanwendungen sind recht portabel und sollt von jedem Browser unterstützt werden. + du kannst die Zugriffe eventuell dokumentieren und widerrufen (gut, ned das was der nutzer schon runtergeladen hat). Grad wenn du von wenig technikaffinen Nutzern sprichst dann bietet sich das an...
Jemand schrieb: > Den 7zip-Pfuschern würde ich in Sachen Krypto nicht mehr vertrauen. > https://threadreaderapp.com/thread/1087848040583626753.html Danke für den Link. Das war mir auch noch nicht bekannt.
zip archiv - kein Passwort! stattdessen den Downloadzugriff hinter einem Login verbergen Browser sind immer in der lage ein Loginform darzustellen ;) Verein ist super..im Newsletter den Link und den Zugang (emails sind eh immer verschlüsselt mittlerweile) wie zB Name "Vereinsitzung 2019" Passwort "fürchterlichgeheim.eV-Gummersbach" (kann man sogar mit der Link URL vorausfüllen wenn man mag) und schwupp zip entpacken geht auf Windoof automatisch, Mac soweit ich weiss auch und Linux Nutzer wissen eh was sie tun :D Dropbox Google und Co Cloud-links kann man auch verteilen per email sogar personifiziert wenn man will. Ansonsten bleibt Dir vermutlich nur der Hardware-weg "bringt nächstemal n usb stick mit, dann kopier ich Euch das!"
Jemand schrieb: > Den 7zip-Pfuschern würde ich in Sachen Krypto nicht mehr vertrauen. > https://threadreaderapp.com/thread/1087848040583626753.html Aber warum gibt es dazu keine CVE Security Meldung? https://www.cvedetails.com/vulnerability-list/vendor_id-9220/7-zip.html Die Verschlüsselungsstärke scheint zwar nach der Changelog verbessert worden zu sein, so viele Änderungen gab es im Code aber nicht. Vieles ist noch so vorhanden, wie bei obigem Link zitiert wurde. Wer nachgucken will, siehe die Datei CPP/7zip/Crypto/RandGen.cpp Hier die Changelog von Version 19: > What's new after 7-Zip 18.06: > > Encryption strength for 7z archives was increased: > the size of random initialization vector was increased from 64-bit to 128-bit, > and the pseudo-random number generator was improved. > Some bugs were fixed. Quelle: https://sourceforge.net/p/sevenzip/discussion/45797/thread/5e7d81bb39/ Es wird immer noch die PID und Zeit für die Seed verwendet. Auch doof ist, dass beim Code für Linux bzw. Unix /dev/urandom anstatt /dev/random verwendet wird. /dev/urandom ist keine gute Wahl für eine Zufallszahl für bspw. nur einen Seed. Die Funktion void CRandomGenerator::Generate(Byte *data, unsigned size) ist immer noch unverändert. Auch der zufällig gewählte hardcodierte SALT Wert ist immer noch im Code enthalten. UInt32 salt = 0xF672ABD1; Einen Hinweis darauf, dass dieser nur noch zum Entpacken alter verschlüsselten 7z Dateien verwendet wird, was zwecks Abwärtskompatibilität ja sein könnte, habe ich auch nicht gefunden. Lediglich hier in der alten Bugmeldung zu diesem Problem findet man noch einen Hinweis, dass die Anzahl der Iteratoren 1000 betragen muss und nicht verändert werden kann, weil das sonst außerhalb der Spec wäre, die WinZip vorgibt. https://sourceforge.net/p/sevenzip/bugs/2176/ Laut Aussagen des Entwicklers, siehe der gerade gepostete link, da ganz unten, muss man sich wegen alten verschlüsselten 7z Dateien aber keine Sorgen machen, da die seinen Aussagen zufolge immer noch sicher seien und die jetzigen Änderungen die Sicherheit lediglich erhöhen würden.
Joachim S. schrieb: > Aber falls dem wirklich so ist: > Clientseitige Entschlüsselung direkt im Webbrowser per JavaScript wäre > die einfachste/benutzerfreundlichste Lösung. Wäre aber natürlich mit > einem gewissen Entwicklungsaufwand verbunden. Die meisten Clouds machen das so. Mega.nz macht das bswp. genau so. Daher kann man Mega hier problemlos verwenden. Der Nachteil von Mega ist lediglich die Anbindung, da Mega immerhin auf der anderen Seite der Erdkugel seine Server hat. Ein weiterer Nachteil ist die Beschränkung bei zu vielen Downloads. Mega riegelt nämlich ab, wenn zu viele Downloaden und dann hat man ein überschrittenes Downloadcontigent, dass man zwar gegen Bezahlung wieder verbessern kann, aber wenn das alles gleich sein soll, dann muss man warten, bis die Begrenzung wieder aufgehoben wurde. Für kleine Dateien für wenige Leute ist das aber okay. Ich habe ein Urlaubsvideo an ca. 20 Leute verteilt und da wurde dann das Downloadcontigent überschritten, einige mussten daher warten bzw. haben die sich mit einem USB Stick ausgeholfen.
'tschuldigung .. Kimmi? wirklich? ist Kim Schmitz Dein ernstgemeinter Vorschlag? Du siehst mich verblüfft, dachte der Dottkommklops ist out mittlerweile
sid schrieb: > 'tschuldigung .. Kimmi? > wirklich? ist Kim Schmitz Dein ernstgemeinter Vorschlag? > Du siehst mich verblüfft, > dachte der Dottkommklops ist out mittlerweile Gerade wenn es um Verschlüsselung geht ist hier doch Mega als Plattform die weitaus bessere Cloud als der ganze Rest der mit den Contentmitarbeitern Geschäfte macht. Denn gerade Mega muss inzwischen darauf achten, dass sie nicht für Contentanbieter angreifenbar werden, also setzen die auf gute Verschlüsselung. Bei Google, Microsoft und Co wäre ich mir da nicht so sicher, da will man gute Konditionen mit den Inhalteanbieter und die würden das nicht gut finden, wenn deren Filme auf der Cloud dieser Anbieter landen. Also liegt es nahe, dass man da in die Cloudinhalte reingucken kann, es wäre jedenfalls naheliegend.
Nano schrieb: >> Haha, das ist wohl ziemlich widersprüchlich. >> >> dgfvlkjdf > > Bei E-Mail gibt es noch, wie ich oben schon sagte, Serverseitige > Verschlüsselung. Wenn es evtl. eine Verschlüsselung gibt, heiß nicht, dass es nur Absender und Empfänger es lesen können. Das hast du nur bei End-to-End-Verschlüsselung, und die muss logischerweise Client-seitig erfolgen. Bei einer nicht selbst verschlüsselten E-Mail sollte man immer davon ausgehen, dass sie etwa so sicher ist wie eine Postkarte. > Bei Geheimdiensten müsste der E-Mail Provider mitspielen, der kann aber > auch im Ausland sitzen. Geheimdienste scheinen für dich das einzige zu sein, wogegen man die Daten schützen muss. Dass die hier relevant sind, wage ich aber zu bezweifeln: MT schrieb: > Die Daten werden öffentlich auf einem Server abgelegt und sind > nicht hochgeheim, aber sollten auch nicht in wenigen Stunden/Tagen zu > knacken sein.
Rolf M. schrieb: > Nano schrieb: >>> Haha, das ist wohl ziemlich widersprüchlich. >>> >>> dgfvlkjdf >> >> Bei E-Mail gibt es noch, wie ich oben schon sagte, Serverseitige >> Verschlüsselung. > > Wenn es evtl. eine Verschlüsselung gibt, heiß nicht, dass es nur > Absender und Empfänger es lesen können. Das hast du nur bei > End-to-End-Verschlüsselung, Richtig, das hast du richtig widergegeben. Der Unterschied zur SMS ist aber, dass da nicht einfach jeder Beliebige mit einem IMSI-Catcher die Daten mitlesen kann. Und auch Länderübergreifend hat man mehr Sicherheit, da Geheimdienste nur bestimmte E-Mail Provider abhören können. > Bei einer nicht selbst verschlüsselten E-Mail sollte man immer davon > ausgehen, dass sie etwa so sicher ist wie eine Postkarte. Im wesentlichen hängt es von deinen Sicherheitsanforderungen ab. Gegenüber wem willst du ein Geheimnis wahren und dann kannst du entsprechend handeln. Terroristen werden nicht einmal mit selbstverschlüsselten E-Mails sich Nachrichten schicken, wenn sie nicht doof sind, weil die Daten wer hatte mit wem eine Verbindung trotzdem überwacht werden könnten. Die treffen sich dann eher mit Technologien, wo es nicht eindeutig ist, wer mit wem spricht. > >> Bei Geheimdiensten müsste der E-Mail Provider mitspielen, der kann aber >> auch im Ausland sitzen. > > Geheimdienste scheinen für dich das einzige zu sein, wogegen man die > Daten schützen muss. Nein, da irrst du dich. Nur ist es so, dass Provider zu Provider Verschlüsselung in der Regel genügt. Du scheinst aber die IMSI Catcher bei der SMS nicht zu kenne, wo jeder mit Ahnung mithören könnte. Daher bezog ich mich hier bei der E-Mail auch auf Geheimdienste, weil die Provider zu Provider Verschlüsselun in der Regel genügt, wenn sie von den beteiligten angewendet wird. Und die meisten Laien nutzen sowieso Webmail, damit hat man schon einmal eine Fehlerquelle weniger, da sie nicht vergessen können ihren E-Mail Clienten richtig zu konfigurieren, da sie den dann ja nicht nutzen und bei Webmail gibt's https bis zum Provider und beim Provider geht's dann bei guten Providern verschlüsselt weiter.
Ich klink mich mal kurz ein: Bzgl. des AES-Themas bei 7z: Das reicht vollkommen aus - der künstliche Hype war lediglich bedingt durch einen etwas lasch eingerichteten Initialisierungsvektor - das wäre tatsächlich ein Problem für ein Unternehmen, das dieselbe (!) Information an verschiedene Empfänger mit verschiedenen Schlüsseln überträgt - dann könnte man mit richtig viel Aufwand (mit Ressourcen à la NSA & Co) auf die Originalinformation zurückschließen. Ein solcher Aufwand trifft für Dich aber nicht zu, also spricht nix gegen 7z mit AES-Verschlüsselung - es ersetzt aber nicht die Verwendung eines "vernünftigen" Passworts. Du schreibst aber auch, daß Deine Empfänger nicht technik-affin sind: Das ist aus meiner Sicht ein viel wichtigers Thema: Wenn jemand nicht mit dem Computer umgehen kann und evtl. USB-Sticks mit (Klartext-) Informationen irgendwo herumliegen läßt, dann darf er schlichtweg keine vertraulichen Informationen erhalten. Punktum!
Christian M. schrieb: >> weniger technikaffine Mitbürger > haben kein > MT schrieb: >> Linux/Mac Ich kenne zwei solcher Exemplare, die ich passender als technikfern bezeichnen würde. Die können Frickelfox und Gockel, bei jedem Problemchen müssen Sohn bzw. Enkel helfen - die haben die Linux-Laptops installiert.
MT schrieb: > Die > Empfänger sind z.T. weniger technikaffine Mitbürger So ist eine sichere Verteilung nicht machbar, ein einziger Depp kann alles kompromittieren. Möglich wäre es, zum Download jeweils einen Einmalschlüssel zu generieren und die Datei für diesen einen Download damit zu verschlüsseln, nach kurzer Zeit verfällt beides. Aber zum einen sind da nicht nur die Mitglieder, sondern auch die Vereinsverwaltung nicht technik-affin genug (muss auf dem Server programmiert werden), und zum anderen ist diese eine downgeloadete Datei ja in der Welt, und besonders wenn der Depp kein Depp, sondern böswillig ist, kann er sie ja weiterverwnden und verteilen. Georg
MT schrieb: > Es sollen für einen Verein Daten sicher per Netz verteilt werden. Die > Empfänger sind z.T. weniger technikaffine Mitbürger, deshalb soll den > Anwendern nicht mehr zugemutet werden wie Datei anklicken -> PW eingeben > -> fertig. > Problem könnte noch sein, dass unbekannt ist, welches Betriebssystem bei > den einzelnen Empfängern genutzt wird. Diese Dateien über eine login-geschützte und natürlich TLS-verschlüsselte Website anzubieten, bietet folgende Vorteile: - eine einfache Einrichtung (alle Webserver und -Browser unterstützen das bereits out of the box) - eine perfekte Usability für Deine Anwender, die diesen Workflow bereits täglich überall nutzen und daher daran gewöhnt sind - vollständige Plattformunabhängigkeit ohne eine Software auf dem Client installieren zu müssen, alles läuft per Browser - es kommen nur authentifizierte und autorisierte Nutzer an die Dateien, und wer die Dateien gar nicht erst bekommt, kann auch nicht versuchen, sie per Dictionary Attack oder Brute Force zu knacken - die Anwender können sich -- innerhalb gewisser Richtlinien -- jeder eigene Paßworte einstellen, die können sie sich besser merken oä. - Du kannst bestimmte Dokumente leicht nur einem eingeschränkten Anwenderkreis zur Verfügung stellen Der Nachteil ist: - die Anwender müssen zuerst Benutzernamen und Paßwort eingeben, und können erst danach auf die Dateien zugreifen... äh, ja. Ansonsten suchst Du wohl Verschlüsselungssoftware wie GnuPG oder PGP, die mit asymmetrischer Verschlüsselung arbeiten und bei denen jede Datei für jeden Anwender individuell geschützt werden kann. Davon gibt es übrigens auch Implementierungen in Java- bzw. EcmaScript -- YMMV.
:
Bearbeitet durch User
Sheeva P. schrieb: > TLS-verschlüsselte Website anzubieten, bietet folgende Vorteile: ... und wer ist alles dort Admin? Kennst Du sie alle? Wahrscheinlich ist die einfachste Lösung auf einer verschlüsselten Webseite eine zip abzulegen, die ein so "hochsicheres" PW wie 000 hat. 3 Nullen kann jeder DAU eintippen, braucht aber Zeit für Unwissende.
oszi40 schrieb: > 1. Müssen alle User die gleichen Daten bekommen, Ja > 2. Müssen sie wieder Daten zurückliefern? Nein > 3. Müssen/dürfen diese Dateien eine begrenzte Haltbarkeit haben? Wäre gut > 4. Man kann auch Daten auf verschiedene Orte verteilen... Split? Es gibt ein Vereinsnetzwerk, bei welchem wir "kostenlos" eine Site hosten dürfen - diese soll auch für die Verteilung genutzt werden > 5. Manches wird erst recht interessant je geheimer es deklariert wurde. Mag sein... Christian M. schrieb: > MT schrieb: >> weniger technikaffine Mitbürger > > haben kein > > MT schrieb: >> Linux/Mac du hast das "z.T." (= zum Teil) überlesen. Und über die Schnittmenge zwischen Inkompetenten und Linux-Usern habe ich nichts gesagt :-) Sheeva P. schrieb: > Diese Dateien über eine login-geschützte und natürlich > TLS-verschlüsselte Website anzubieten, bietet folgende Vorteile: Kann man das auch auf einer selbst einrichten? Rahmenbedingungen: - uns steht Speicherplatz zum hosten einer Site zur Verfügung - auf dem Server können keine Pakete installiert / administrativen Veränderungen vorgenommen werden (bzw. nur auf Anfrage beim Vereinsnetzwerk) Hab leider wenig Ahnung davon, hättest du nen Link etc. zum einlesen? Ansonsten gefällt mir die Idee natürlich und ich würde es dann so vorschlagen - den oberen ist vor allem wichtig, dass die Daten auf "unserem" Server liegen, das es einfach ist und nichts zusätzlich kostet (also das Übliche) > Der Nachteil ist: > > - die Anwender müssen zuerst Benutzernamen und Paßwort eingeben, und > können erst danach auf die Dateien zugreifen... äh, ja. Sollte verkraftbar sein, bzw. kann man das ja teilweise unterstützen
oszi40 schrieb: > Sheeva P. schrieb: >> TLS-verschlüsselte Website anzubieten, bietet folgende Vorteile: > > ... und wer ist alles dort Admin? Kennst Du sie alle? Das dürfte doch nun keine allzu große Schwierigkeit darstellen, meinst Du nicht? Mir sind Vereine, Unternehmen, Behörden und allerlei Organisationen aller Größenordnungen bekannt, die dieses Problem gelöst bekommen... > Wahrscheinlich ist die einfachste Lösung auf einer verschlüsselten Webseite > eine zip abzulegen Und die darf wer hochladen? Ach ja, der besagte Admin... nur braucht Dein Admin dann einen Zugang per FTP(S) oder SFTP oä., und kann damit wohl mehr kaputt machen -- absichtlich oder versehentlich -- als ein authentifizierter und autorisierter Webuser... Naja, YMMV. > die ein so "hochsicheres" PW wie 000 hat. 3 Nullen kann jeder > DAU eintippen, braucht aber Zeit für Unwissende. Spaßeshalber habe ich das gerade zweimal mit fcrackzip(1) per Bruteforce ausprobiert... Auf meinem antiken Q9650 wurde das Paßwort "000" einmal in 0,096 und einmal in 0.068 Sekunden geknackt... herzlichen Dank für Deinen Beitrag. Ist das schon Social Engineering? ;-)
MT schrieb: > Sheeva P. schrieb: >> Diese Dateien über eine login-geschützte und natürlich >> TLS-verschlüsselte Website anzubieten, bietet folgende Vorteile: > > Kann man das auch auf einer selbst einrichten? > Rahmenbedingungen: > - uns steht Speicherplatz zum hosten einer Site zur Verfügung > - auf dem Server können keine Pakete installiert / administrativen > Veränderungen vorgenommen werden (bzw. nur auf Anfrage beim > Vereinsnetzwerk) > > Hab leider wenig Ahnung davon, hättest du nen Link etc. zum einlesen? > > Ansonsten gefällt mir die Idee natürlich und ich würde es dann so > vorschlagen - den oberen ist vor allem wichtig, dass die Daten auf > "unserem" Server liegen, das es einfach ist und nichts zusätzlich kostet > (also das Übliche) Dies hier ist ein ganz guter Einstieg: https://de.wikipedia.org/wiki/HTTP-Authentifizierung Diese Art der Authentifizierung ist Bestandteil des HTTP-Standards und damit in jedem üblichen Webserver und -Browser bereits eingebaut. Es hängt allerdings von der konkreten Webserversoftware ab, wie das konfiguriert wird, dazu fragst Du am Besten die Techniker vom Vereinsnetzwerk. Das ist ein so üblicher Anwendungsfall, daß es mich sehr wundern würde, wenn ein darauf spezialisierter Hoster keine Lösung(en) für so etwas anbietet. Davon abgesehen kostet ein kleiner Webspace mit Domain, 10 GB Speicher, Admin-Interface und TLS-Zertifikat bei Hetzner nur 1,90 € pro Monat -- da geht das definitiv und der Preis ist vermutlich auch für kleine Vereine noch gerade so zu stemmen... ;-) >> Der Nachteil ist: >> >> - die Anwender müssen zuerst Benutzernamen und Paßwort eingeben, und >> können erst danach auf die Dateien zugreifen... äh, ja. > Sollte verkraftbar sein, bzw. kann man das ja teilweise unterstützen Najaaa... das Paßwort benötigen sie ohnehin, bleiben als "zusätzliche Komplexität" also nur die Reihenfolge und der Benutzername... und als Benutzernamen könnte man etwa auch ihre E-Mailadresse nehmen, die kennen auch unbedarfte Benutzer meistens auswendig.
Sheeva P. schrieb: > Auf meinem antiken Q9650 wurde das Paßwort "000" einmal > in 0,096 und einmal in 0.068 Sekunden geknackt.. WENN Deine Datei von einer verschlüsselten Seite kommt, sind schon mal einige User ausgeschlossen? Dann nimm doch heute ein besseres PW für die zip als bei Heise am 04.12.2013 beschrieben! :-) https://www.heise.de/security/meldung/00000000-Passwort-fuer-US-Atomraketen-2060077.html Sicher ist ein längeres PW mit x kryptischen Sonderzeichen usw. noch besser, aber für einen Kegelverein wird es wohl eher um einfachen Datenschutz und ungewollte Verbreitung gehen? Wetten, dass im Verein in 20 Jahren auch der einfachste Schlüssel verloren geht?
oszi40 schrieb: > Sheeva P. schrieb: >> Auf meinem antiken Q9650 wurde das Paßwort "000" einmal >> in 0,096 und einmal in 0.068 Sekunden geknackt.. > > WENN Deine Datei von einer verschlüsselten Seite kommt, sind schon mal > einige User ausgeschlossen? Dann nimm doch heute ein besseres PW für die > zip als bei Heise am 04.12.2013 beschrieben! :-) > https://www.heise.de/security/meldung/00000000-Passwort-fuer-US-Atomraketen-2060077.html > Sicher ist ein längeres PW mit x kryptischen Sonderzeichen usw. noch > besser, aber für einen Kegelverein wird es wohl eher um einfachen > Datenschutz und ungewollte Verbreitung gehen? Wetten, dass im Verein in > 20 Jahren auch der einfachste Schlüssel verloren geht? Die 000 war Dein Vorschlag, nicht meiner. Du hattest behauptet, daß das ein ausreichend siches Paßwort sei. Abgesehen davon, daß mein kleiner Test wohl bewiesen hat, daß Dein Vorschlag keinerlei Sicherheit bietet, empfinde ich Deine ganze "Argumentation" als äußerst merkwürdig, diplomatisch gesagt. Erstens bleibt es mir schleierhaft, warum eine nach dem TLS-Standard verschlüsselte Webseite irgendwelche User ausschließen sollte. Das TLS-verschlüsselte HTTP (auch als HTTPS bekannt) ist DER Standard für den sicheren Zugang zu Webseiten, jeder handelsübliche Browser beherrscht diesen Standard ohne weiteres Zutun. Ganz anders hingegen alle hier vorgeschlagenen Lösungen mit clientseitiger Verschlüsselungssoftware, welche natürlich zunächst einmal auf dem Client installiert sein und plattformunabhängig werden müßte -- schwierig auch, weil nicht alle Benutzer auf ihren Rechnern selbständig Software installieren dürfen. Zweitens ist mir einigermaßen schleierhaft, was die Zugangscodes von US-amerikanischen Atomwaffen mit dem Thema zu tun haben, und ich bin äußerst gespannt auf Deine näheren Erläuterungen zu diesem Thema. Danke. Drittens ist der OP einigermaßen schwammig in seinen Ausführungen zu dem geforderten Sicherheitsniveau, weswegen ich es ausgesprochen unseriös und auch ein wenig anmaßend finde, Annahmen dazu zu treffen und auf der Basis dieser Deiner Angaben gegen eine Lösung zu "argumentieren", die sich an die einschlägigen Standards hält, ein hohes Sicherheitsniveau bietet, mit dem allseits geringstmöglichen Aufwand eingerichtet werden kann und darüber hinaus weitere Vorteile bietet, wie im Folgenden angedeutet. Auch Deine Ausführungen zum "einfachen Datenschutz" und der "ungewollten Verbreitung" erschließen sich mir nicht. Wenn die Dat(ei)en nur über eine zugriffsgeschützte Webseite heruntergeladen werden können, dann kümmert sich doch die Webseite um die Authentifizierung und Autorisierung der Anwender. Ein weiterer Schutz für die konkreten Dateien ist in dem Falle gar nicht mehr notwendig, weil die Dateien ohnehin nur von autorisierten Anwendern heruntergeladen werden können -- und gegen das Problem, daß ein autorisierter Anwender die heruntergeladenen Dat(ei)en weitergibt, hilft Deine ZIP-"Verschlüsselung" auch nicht, denn was hindert den böswilligen Anwender daran, die entschlüsselte Version der Datei weiterzugeben? Im Gegensatz zu Deinen Vorschlägen ist es zudem so, daß meine Lösung gar keinen Schlüssel benötigt, der verteilt werden müßte, sondern lediglich eine serverseitige Authentifizierung und Autorisierung -- anders gesagt: dazu müssen lediglich Login-Credentials vergeben werden, so daß sich das Problem von verlorenen Schlüsseln gar nicht stellt. Weil die Credentials aber serverseitig geprüft und verwaltet werden, bietet meine Lösung also obendrein auch noch den charmanten Vorteil, daß der Betreiber einfach ein neues Paßwort setzen kann, wenn die Zugangsdaten vergessen wurden. Hinzu kommt, daß auch Nutzern einfach der Zugang entzogen werden kann, wenn sie aus dem Verein ausscheiden und keine neuen Dokumente mehr sehen sollen -- bei Deinem Szenario wäre das eher schwierig. Schau, ich verlagere einfach den Fokus der ganzen Geschichte dahin, wo er hingehört: weg vom Schutz der konkreten Dateien und stattdessen auf den Zugang zu diesen Dateien. Ein Angreifer, der eine Datei gar nicht erst herunterladen kann, weil diese in einem geschützten Bereich liegt, kann natürlich auch keine Dictionary- oder Bruteforce-Angriffe auf das Paßwort ausführen, weil er die Datei schlicht und ergreifend gar nicht hat. Klar kann er einen ählichen Angriff auf die Login-Credentials der geschützten Website versuchen, aber dabei sind sein Aufwand und sein Entdeckungsrisiko deutlich höher. Außerdem sind serverseitige Gegenmaßnahmen möglich, zum Beispiel die HTTP-Response bei fehlerhaften Credentials zu verzögern oder nach einer entsprechenden Anzahl fehlgeschlagener Logins die IP-Adresse eines Angreifers temporär zu blockieren, oder den angegriffenen Account nach n fehlerhaften Login-Versuchen zu sperren. Trotz allem, vielen Dank für Deine Beiträge. Bitte vergiß' nicht, mir den Zusammenhang mit den Atomcodes zu erklären, ja? Dankeschön! ;-)
oszi40 schrieb: > Sicher ist ein längeres PW mit x kryptischen Sonderzeichen usw. noch > besser, aber für einen Kegelverein wird es wohl eher um einfachen > Datenschutz und ungewollte Verbreitung gehen? Wetten, dass im Verein in > 20 Jahren auch der einfachste Schlüssel verloren geht? https://www.xkcd.com/936/ "Das ist der tollste Kegelverein der Welt" Wird man in 20 Jahren auch noch wissen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.