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.
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
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...
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.
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.
