Hallo, ich habe ein Programm erstellt mit der (WIN32 API, C / C++) welches Text-Dateien auf die Festplatte schreibt. Jetzt suche ich eine Möglichkeit die Dateien mit einem Passwort zu schützen (ähnlich wie bei einem ZIP-File), sodass keiner die Dateien ohne Passwort öffnen kann. Die Dateien sollen dabei nicht verschlüsselt werden. Wie mache ich das am einfachsten? Danke und Gruß Peter
:
Verschoben durch User
Hallo! Reine Textdateien haben keinen Kennwortschutz. Da musst Du ein anderes Dateiformat wählen. Oder Du schützt den Speicherpfad mit einem entsprechenden Programm. Gruß, René
:
Bearbeitet durch User
Peter schrieb: > Jetzt suche ich eine Möglichkeit die Dateien mit einem Passwort zu > schützen (ähnlich wie bei einem ZIP-File), sodass keiner die Dateien > ohne Passwort öffnen kann. Die Dateien sollen dabei nicht verschlüsselt > werden. Was soll das Bringen? Ohne Verschlüsselung kann die doch jeder lesen. Wenn du nur einen Passwortschutz willst, schreibe das Passwort an den Anfang deiner Textdatei und bringe deinem Programm bei, die Datie nur nach Eingabe dieses Passwortes zu öffnen. Ist zwar kompletter Schwachsinn weil jeder die Datei anderweitig öffnen und lesen kann, aber es ist im Endeffekt das was du forderst.
:
Bearbeitet durch User
Hi, ohne Verschlüsselung macht ein Passwort echt keinen Sinn. Kannst ja mal Veruche machen mit
1 | fprintf (file, "Wer das Passwort %s nicht kennt, darf jetzt nicht weiter lesen !!!\r\n\r\n", passwort); |
Du könntest Dateien im Dateisystem NTFS vom Betriebssystem verschlüsseln lassen und festlegen, welche Benutzer die Datei lesen dürfen. Ansonsten bleibt Dir echt nur ein anderes Dateiformat zu wählen. Ein .zip in der Deine Textdatei Passwortgeschützt steckt wäre dabei sogar ziemlich universell. Ein passwortgeschütztes MS-Office Dokument schränkt die Leserschaft schon mehr ein. Oder noch eingeschränkter ist ein ausführbares Programm, dass das Passwort abfragt und dann bei richtiger Eingabe den Text anzeigt.
Es handelt sich offensichtlich um ein Windows Programm. Der Zugriff auf die unverschlüsselte Datei soll nur mit einem Passwort möglich sein. Ist doch ganz einfach: Dazu verwendet man das Rechtesystem von Windows. Man legt ein Verzeichnis an, auf das nur ausgewählte Benutzer Zugang haben. Diese müssen sich mit ihren Passwort einloggen, damit sie Zugriff auf die Datei erhalten. Was hat das mit Mikrocontrollern zu tun?
Ich muss das genauer erläutern: Meine Software schreibt im Debug-Modus eine Textdatei auf die Festplatte (mit Debug-Informationen). Diese Debug-Informationen sollen nur von mir selbst gelesen werden können (deshalb das Passwort). Ich möchte dann einfach die Datei doppel klicken, das Passwort eingeben und mir dann die Debug-Informationen im Text-Editor anschauen. Die Datei soll sich also ohne Passwort erst gar nicht öffnen lassen. Wenn ich so überlege, glaube ich, dass das auch mit ZIP nicht geht, da man den Dateiinhalt auch ohne Passwort einsehen kann, oder? Gruß Peter
Stefanus F. schrieb: > Es handelt sich offensichtlich um ein Windows Programm. Der Zugriff auf > die unverschlüsselte Datei soll nur mit einem Passwort möglich sein. > > Ist doch ganz einfach: Dazu verwendet man das Rechtesystem von Windows. > Man legt ein Verzeichnis an, auf das nur ausgewählte Benutzer Zugang > haben. Diese müssen sich mit ihren Passwort einloggen, damit sie Zugriff > auf die Datei erhalten. > > Was hat das mit Mikrocontrollern zu tun? Nichts, sorry. Bitte verschieben nach PC Programmierung.
Peter schrieb: > sodass keiner die Dateien > ohne Passwort öffnen kann. Die Dateien sollen dabei nicht verschlüsselt > werden. Aha, und wie soll das funktionieren?
Peter schrieb: > Wenn ich so überlege, glaube ich, dass das auch mit ZIP nicht geht, da > man den Dateiinhalt auch ohne Passwort einsehen kann, oder? Natürlich geht das mit ZIP, denn ZIP-Dateien können mit einem Passwort verschlüsselt werden. Das ist der Weg für Deinen Ansatz. Wenn Du Deinen Doppelklick ausführst, wirst Du nach dem Passwort gefragt. Die semantische Feinheit "passwortgeschützt aber nicht verschlüsselt" diskutieren wir jetzt mangels Sinn nicht weiter aus.
Peter schrieb: > Wie mache ich das am einfachsten? Ein Informatik-Studium belegen, um Grundlagen zu lernen. Ohne Verschlüsselung (auch direkt mit dem Passwort als Verschlüsselungskey) wird das nichts, denn unverschlüsselte Textdateien sind immer direkt lesbar. Damit wird ein Öffnen mit normalen Texteditor nichts, denn der Editor müsste Entschlüsseln (wozu er dann das Passwort braucht). Man kann natürlich die Textdatei in ein ZIP verpacken, aber das willst du ja nicht.
Peter schrieb: > Ich möchte dann > einfach die Datei doppel klicken, das Passwort eingeben und mir dann die > Debug-Informationen im Text-Editor anschauen Selbst wenn du dir die Mühe machst, so ein Programm zu schreiben, ist das ohne Verschlüsselung total sinnlos. Man schaut sich die Datei mit einem Hex-Editor an, oder auch ganz einfach mit Notepad, und liest den Text oder kopiert in heraus. Georg
Dann leg ich mich mal auf ZIP-Datei / -Verschlüsselung fest. Gibt es sowas (oder ähnliches) in der WIN32 API? Was könnt ihr mir als Alternative empfehlen? Danke Peter
Peter schrieb: > Gibt es sowas (oder ähnliches) in der WIN32 API? Nicht direkt, aber eine Library zum Erstellen von ZIP-Dateien zu finden, die man in ein mit der Win32-API geschriebenes Programm einbetten kann, ist keine Raketenwissenschaft, sondern dauert nur ein paar Minuten. Ein alternativer Ansatz ist die Verwendung der Automationsschnittstelle des Shell32-Objekts: https://vcpptips.wordpress.com/tag/windows-shell32/
Hast du vergessen, wie man Google benutzt? Das war das erste Ergebnis, das ich gefunden habe: https://msdn.microsoft.com/en-us/library/windows/desktop/hh920921(v=vs.85).aspx Sieht vielversprechend aus.
Soll Dein Programm auch beim Kunden Debuginfos schreiben können oder nur bei Dir während der Fehlersuche ? Im zweiten Fall wäre ja auch ein undokumentierter Aufrufparameter wie "--debug:passwort" Deines Programms denkbar, ohne den die Datei erst gar nicht geschrieben wird.
fop schrieb: > Soll Dein Programm auch beim Kunden Debuginfos schreiben können oder nur > bei Dir während der Fehlersuche ? Meiner Erfahrung nach sind immer die Debuginfos wichtig, die man gerade nicht hat. Immer so viel Daten loggen wie nötig macht da schon Sinn.
fop schrieb: > Soll Dein Programm auch beim Kunden Debuginfos schreiben können oder nur > bei Dir während der Fehlersuche ? Eigentlich nur beim Kunden. Bei mir seh ich das über OutputDebugString(). Stefanus F. schrieb: > Hast du vergessen, wie man Google benutzt? Nein, wenn aber hier schon jemand soetwas eingebunden / gemacht hat und es für gut empfunden hat, dann nehm ich gerne die Empfehlung. Danke Peter
vn n. schrieb: > Meiner Erfahrung nach sind immer die Debuginfos wichtig, die man gerade nicht hat. Stimmt, Betonung auf "gerade nicht hat". > Immer so viel Daten loggen wie nötig macht da schon Sinn. Auch da fehlen erfahrungsgemäß immer die, die man nicht für nötig erachtet hat, zu schreiben. Also schreibt man alles was geht und erfreut sich daran, dass der Speicherplatz auseinander fliegt.
Um für Textdateien einen Schutz zu haben musst du alle Infos verschlüsseln. Der Schlüssel (Passwort) dient in diesem Fall zur Ver- und Endschlüsselung.
Ernsthaft jetzt? Kryptische error codes sind nicht mehr gut genug, jetzt muss man alle Hinweise ganz unlesbar machen? Was steht denn in dem Logfile, was der Kunde nicht sehen darf? Wenn ich so ein Programm hätte, würde ich sofort mal nachsehen, was man mich da nicht sehen lassen will. Solange das Programm bei mir liegt kann man dagegen ja absolut nichts machen.
Manfred schrieb: > Also schreibt man alles was geht und erfreut > sich daran, dass der Speicherplatz auseinander fliegt. In heutigen Zeiten eher kein Problem. Man kann ja z.B. einen Ringbuffer bauen, die Daten von vor zwei Jahren interessierne eh keinen.
Wie wär's, die Datei mit z.B. der Endung *.dat zu versehen? Dann geht sie beim normalen Anklicken nicht direkt auf, und ist nicht als Textdatei zu erkennen...
StefG schrieb: > Wie wär's, die Datei mit z.B. der Endung *.dat zu versehen? > Dann geht sie beim normalen Anklicken nicht direkt auf, und ist nicht > als Textdatei zu erkennen... Er will sie aber direkt anklicken. Und es soll (nach der Eingabe des Passwortes) der Texteditor aufgehen. Wie das gehen soll, ist mir zwar schleierhaft, aber so ist der Wunsch des TO. Wenn es eine Textdatei ist, aber nicht verschlüsselt ist, nimmt man einen beliebigen anderen Texteditor oder -Betrachter und liest sie einfach. Selbst wenn man es im Windows mit Benutzerrechten macht, kopiert man die Textdatei auf einen Rechner mit Linux und liest die Datei. Fazit: So wie der TO es sich vorstellt, GEHT ES NICHT.
Ich hab mir das auch nochmal überlegt und werde wohl hergehen und die Strings mit XOR verwursten. Das sollte reichen an 'Verschlüsselung'. Danke Peter
Hmm, erstmal halte ich es auch für eine bescheidene Idee Debug-Logs zu verschlüsseln; aber wenn es wegen der Inhalte sein muss meinetwegen. Das Problem bei einer Zip Datei ist ja, dass sie erst nach ihrer Fertigstellung gezippt und verschlüsselt wird. Wenn das Programm also crasht, steht da erstmal die unverschlüsselte Datei und bleibt auch so. (Korrigiert mich, wenn es eine Zeilenappend in Zip Dateien gibt) Ich würde jede einzelne Zeile verschlüsseln, dann in die Datei schreiben und bei Dir vor Ort mit einem Mini-Programm entschlüsseln. Beim Algorithmus musst du zwischen Effizienz und Sicherheit abwägen: XOR, symetrisch mit AES oder sogar asymetrisch.
Peter schrieb: > Ich hab mir das auch nochmal überlegt und werde wohl hergehen und > die > Strings mit XOR verwursten. Das sollte reichen an 'Verschlüsselung'. > > Danke Peter Fehlt noch der Passwort-Schutz (dein eigentliches Ziel).
Hugo E. schrieb: > Fehlt noch der Passwort-Schutz (dein eigentliches Ziel). Aber das wars doch gar nicht. Mensch Hugo, zwischen den Zeilen lesen!
Was ist am Debug-Log eigentlich so irrwitzig geheim, daß das vor den Benutzern der Software ferngehalten werden muss? Anfangen können die mit Debug-Infos i.d.R. eh' nichts. Andere Softwarehersteller haben kein Problem damit, wenn Debuginfos "offen" herumliegen. Was machst Du anderes?
Rufus Τ. F. schrieb: > Was ist am Debug-Log eigentlich so irrwitzig geheim, daß das vor den > Benutzern der Software ferngehalten werden muss? > > Anfangen können die mit Debug-Infos i.d.R. eh' nichts. > > Andere Softwarehersteller haben kein Problem damit, wenn Debuginfos > "offen" herumliegen. > > Was machst Du anderes? Naja, prinzipiell sind Debug-Infos nicht für den Kunden gedacht und gehen ihn auch nichts an.
Rufus Τ. F. schrieb: > Andere Softwarehersteller haben kein Problem damit, wenn Debuginfos > "offen" herumliegen. Da gibt es dann meist noch ein Programm, mit dem alle benötigetn Infos/Logdateien zusammen gezipt werden, um die dann per Mail an den Service zu schicken.
Hier wird genau das behandelt was du möchtest, dank C++ einfach zu nutzen: https://www.spieleprogrammierer.de/27-tutorials/6124-lesen-schreiben-von-verschl%C3%BCsselten-zip-archiven/
Peter schrieb: > Naja, prinzipiell sind Debug-Infos nicht für den Kunden gedacht und > gehen ihn auch nichts an. Es ist eine Frage des Vertrauens, welche Daten der Kunde dem Softwareanbieter zur Verfügung stellt. Die Debuginfos gehören zunächst dem Kunden, denn sie sind auf seinem Rechner entstanden und können daher auch persönliche Daten des Kunden enthalten. Der Kunde weiß nicht, was für Daten das sind, die Du da einsammeln willst - tatsächlich nur Debuginfos, oder vielleicht ... doch etwas mehr? Ein paar Passwörter/Kreditkartendaten gefällig, die ein zur Software gehörender Keylogger eingesammelt hat? Mit Offenheit kann man all' diese Verdächtigungen aus der Welt schaffen. Lass' den Kunden in seine Debuginfos reinschauen. Auch wenn die Daten --natürlich-- dem Kunden nichts sagen werden, mit etwas Erfahrung wird er in der Lage sein, z.B. einen Stacktrace von Keyloggerdaten unterscheiden zu können. Oder hast Du Angst, daß die geheime Funktion Deines Programmes durch Betrachten der Debuginfos erraten werden könnte und so Deine Geschäftsgrundlage flöten geht? Sieh Dir die Diskussionen um die sogenannten "Telemetriedaten" von Microsoft an. Fühlst Du Dich mit so etwas gut?
Dirk B. schrieb: > Da gibt es dann meist noch ein Programm, mit dem alle benötigetn > Infos/Logdateien zusammen gezipt werden, um die dann per Mail an den > Service zu schicken. Rufus Τ. F. schrieb: > Der Kunde weiß nicht, was für Daten das sind, die Du da einsammeln > willst - tatsächlich nur Debuginfos, oder vielleicht ... doch etwas > mehr? Ein paar Passwörter/Kreditkartendaten gefällig, die ein zur > Software gehörender Keylogger eingesammelt hat? Immer wenn ich meinen Rechner einschalte, gehe ich davon aus, dass alles was ich daran mache von irgendjemandem mitprotokolliert wird. Ich hoffe dann immer, dass meine Daten einfach nicht wichtig genug sind, sodass sich keiner die Mühe macht sich das Zeugs anzuschauen. Was Passwörter und Kreditkarteninformationen anbelangt, so kann man sich die auch Millionenfach im Internet kaufen. Ganz ohne Software-Entwicklung. Was meine Debug-Datei anbelangt, kann ich die natürlich auch im Klartext versenden, sodass der Kunde alles sieht. Wenn ich dann die Kreditkartennummer mitverschicken will, dann teil ich die in 5 Teile auf und schreib die Zahlen von hinten nach vorne. Meinst Du bei 1 MByte Logfile-Größe fällt das irgendwie auf, wenn da überall Parameter angegeben sind und deren Werte? Ich glaube nicht.
Peter schrieb: > Hugo E. schrieb: >> Fehlt noch der Passwort-Schutz (dein eigentliches Ziel). > > Aber das wars doch gar nicht. Mensch Hugo, zwischen den Zeilen lesen! Was war's denn dann? Lesen wir zusammen mal den Titel: > Re: Passwort-Schutz für Textdatei Und was steht jetzt "zwischen den Zeilen", was ich evtl. überlesen hab? ;-)
Hugo E. schrieb: > Was war's denn dann? > Lesen wir zusammen mal den Titel: >> Re: Passwort-Schutz für Textdatei > > Und was steht jetzt "zwischen den Zeilen", was ich evtl. überlesen hab? > ;-) Es ist wie bei einem Buch: Man darf nicht nur den Titel lesen ;)
Hugo E. schrieb: > Lesen wir zusammen mal den Titel: >> Re: Passwort-Schutz für Textdatei > > Und was steht jetzt "zwischen den Zeilen", was ich evtl. überlesen hab? > ;-) >> Re: Passwort-Schutz für Textdatei ^ ^ ^ Hier sind jeweils einige Geheimnisse versteckt.
Peter schrieb: > Meinst Du bei 1 MByte Logfile-Größe fällt das irgendwie auf, wenn da > überall Parameter angegeben sind und deren Werte? > Ich glaube nicht. Und was war nochmal das Argument dafür, daß der Nutzer Deiner Software nicht sehen darf, was in Deinen "Debug"-Dateien drinsteht?
Peter schrieb: > Naja, prinzipiell sind Debug-Infos nicht für den Kunden gedacht und > gehen ihn auch nichts an. ?!? Wie soll die Bananen-Software denn da beim Kunden reifen ? Mir reicht schon mein mAuto, welches sämtliche ihm bekannten Fehlermeldungen geheim hält und nur mit einer einzigen Lampe anzeigt, dass es da wohl irgendwo irgendeinen Fehler gäbe. Das sollte unter Strafe stehen von nicht weniger als 10 Jahren Zuchthaus.
Rufus Τ. F. schrieb: > Und was war nochmal das Argument dafür, daß der Nutzer Deiner Software > nicht sehen darf, was in Deinen "Debug"-Dateien drinsteht? Umgekehrt wird ein Schuh draus: Deine Argumente ziehen nicht, oder? Deine Argumente ziehen nicht, wenn ich bei Klartext auch die Passwörter verstecken kann. Ich brauch kein Argument, um die Debug-Dateien unleserlich zu gestalten. Es geht den Kunden einfach nichts an. MaWin schrieb: > ?!? Wie soll die Bananen-Software denn da beim Kunden reifen ? > > Mir reicht schon mein mAuto, welches sämtliche ihm bekannten > Fehlermeldungen geheim hält und nur mit einer einzigen Lampe anzeigt, > dass es da wohl irgendwo irgendeinen Fehler gäbe. > > Das sollte unter Strafe stehen von nicht weniger als 10 Jahren > Zuchthaus. Ich würde das ja gerne kommentieren. Aber soweit bin ich noch nicht.
> Es geht den Kunden einfach nichts an.
Das sehe ich aber ganz anders. Mich geht es ALLES an, was mein Computer
so treibt. Ich bin ja schließlich auf dafür verantwortlich.
Stefanus F. schrieb: > Das sehe ich aber ganz anders. Mich geht es ALLES an, was mein Computer > so treibt. Ich bin ja schließlich auf dafür verantwortlich. Man kann das durchaus auch so sehen. Ich aber bin der Meinung, das ich auch bei unverschlüsselter Datei irgendetwas klauen kann, ohne das der Kunde etwas mitbekommt und somit macht es keinen Unterschied ob verschlüsselt oder unverschlüsselt.
Peter schrieb: > Ich brauch kein Argument, um die Debug-Dateien unleserlich zu gestalten. > Es geht den Kunden einfach nichts an. Ich mag die Abmahnmafia ja auch nicht, aber dich sollten sie mal nach der DSGVO in die Mangel nehmen. Danach bist du sowieso pleite. Georg
Peter schrieb: > Ich brauch kein Argument, um die Debug-Dateien unleserlich zu gestalten. > Es geht den Kunden einfach nichts an. Mit anderen Worten: Der Kunde darf dir sein Geld geben aber hat ansonsten das Maul zu halten. Jetzt weiß ich wenigstens bei wem ich auf keinen Fall Kunde sein will...
:
Bearbeitet durch User
Was soll denn dieser Schwachsinn schon wieder? Null Programmiererfahrung aber schon die hochgeheimen staatstragenden Debug-Logs verschlüsseln müssen, gehts noch? Das letzte Mal als ich solcherlei Unfug von einem kommerziellen Programm gesehen habe hab ich mich augenblicklich von dem Schrott abgewendet und nie mehr zurückgeblickt. Mal ganz davon abgesehen daß so eine Verarschung grundsätzlich eine Geringschätzung und geradezu eine Beleidigung der Intelligenz der Anwender darstellt. Die Daten des Anwenders auf dessen eigener Maschine gegen ihn selbst zu verschlüsseln, ich glaub mein Schwein pfeift. Geh lieber wieder Rosen züchten oder Briefmarken sammeln oder was auch immer Du gemacht hast bevor Du letzte Woche auf den Trichter mit dem Programmieren gekommen bist und behalt Dein Zeug für Dich, dann bringst Du wenigstens nicht so viele Leute gegen Dich auf und verursachst kein öffentliches Ärgernis. . Man-o-mann, ich komm gar nicht mehr runter, so sehr muss ich mich über so einen bodenlosen Schwachsinn aufregen. Bleib mir bloß gestohlen mit Deiner Schrottsoftware, ich sags Dir!
:
Bearbeitet durch User
Hatte erst letztes Jahr so n Fall, da ist der Rechner beim Öffnen des Logs abgeschmiert und das Logfile hatte >300MB weil der Softwarehersteller jeden Furz da reingeschrieben hat und keine Löschung in seiner Software vorsah. Der Anwender war nah am Verzweifeln. Glückwunsch, Software 'Made in Germany'. Gut, hat sich herausgestellt, das das Log n SQLight-File war und die Logtabelle einfach per DELETE * bereinigt werden konnte, aber ärgerlich wars schon.
Stefanus F. schrieb: > Mich geht es ALLES an Genau so ist es, und nach DSGVO muss der Kunde detailliert informiert werden, welche Daten von ihm erfasst werden, und er muss damit sein Einverständnis erklären. Natürlich missachtet der TO das. Es ist zwar nicht erwiesen, dass er unlautere Zwecke mit seinen Daten erfolgt, aber die Haltung dazu " Ich brauch kein Argument, um die Debug-Dateien unleserlich zu gestalten. Es geht den Kunden einfach nichts an." spricht doch sehr dafür, dass sein Vorhaben kriminell ist, sonst müsste er die übermittelten Daten ja nicht verschleiern. Deshalb sollte man das auch nicht unterstützen. Georg
Peter schrieb: > Naja, prinzipiell sind Debug-Infos nicht für den Kunden gedacht und > gehen ihn auch nichts an. Da er aber auch nichts damit anfangen kann (außer um dir ggf. bei der Fehlersuche zu helfen), interessieren diese Ausgaben den Kunden auch gar nicht. MaWin schrieb: > Mir reicht schon mein mAuto, welches sämtliche ihm bekannten > Fehlermeldungen geheim hält und nur mit einer einzigen Lampe anzeigt, > dass es da wohl irgendwo irgendeinen Fehler gäbe. Das haben sie sich von Microsoft abgeschaut. Da haben die Fehlermeldungen häufig einen ähnlich hohem Aussagegehalt. Peter schrieb: > Ich aber bin der Meinung, das ich auch bei unverschlüsselter Datei > irgendetwas klauen kann, ohne das der Kunde etwas mitbekommt und somit > macht es keinen Unterschied ob verschlüsselt oder unverschlüsselt. Jetzt hast du es verstanden: Es macht keinen Unterschied, deshalb ist es vergebene Liebesmühe, hier unbedingt eine Verschlüsselung einbauen zu wollen. Lediglich wird sich der Kunde ggf. fragen, was du dir da für Daten von seinem Rechner holst, von denen er nichts wissen darf. Manfred F. schrieb: > Mit anderen Worten: Der Kunde darf dir sein Geld geben aber hat > ansonsten das Maul zu halten. Diese Einstellung grassiert gerade ziemlich bei Software-Herstellern.
georg schrieb: > Stefanus F. schrieb: >> Mich geht es ALLES an > > Genau so ist es, und nach DSGVO muss der Kunde detailliert informiert > werden, welche Daten von ihm erfasst werden, und er muss damit sein > Einverständnis erklären. > > Natürlich missachtet der TO das. Wieso missachtet der TO die DSVGO? Das kann zwar sein ist aber mit den vorliegenden Infos nicht festzustellen. 1. Wenn keine personenbezogenen Daten betroffen sind, ist die DSVGO außen vor, wenn nicht dann: 2. Wenn er eine eindeutige Datenschutzerklärung hat ist der DSVGO Genüge getan, sofern überhaupt relevant. (siehe 1) 3. Da der TO die Daten auch versenden will, müssen personenbezogene Daten gemäß DSVGO dazu verschlüsselt sein. Das Vorhaben des TO mag zwar unschön und wenig kundenfreundlich sein aber hier derart mit der DSVGO zu winken ist genauso Unsinn. Das ist wie mit WiFi-Spray Funkstörungen beseitigen zu wollen.
werists schrieb: > 3. Da der TO die Daten auch versenden will, müssen personenbezogene > Daten gemäß DSVGO dazu verschlüsselt sein. Die Datei muss es aber beim client nicht sein. Es reicht, wenn ein sicherer transport, wie z.B. TLS bei der Datenübertragung verwendet wird. Wenn man will, kann man die dann Serverseitig auch immernoch verschlüsseln.
Rolf M. schrieb: > Peter schrieb: >> Naja, prinzipiell sind Debug-Infos nicht für den Kunden gedacht und >> gehen ihn auch nichts an. > > Da er aber auch nichts damit anfangen kann (außer um dir ggf. bei der > Fehlersuche zu helfen), interessieren diese Ausgaben den Kunden auch gar > nicht. Schlechte Einstellung. Wenn der Kunde nicht weiss was der Hersteller an Daten des Kundenrechners sammelt, könnte der Hersteller auch solche Daten sammeln die den Hersteller und seinen Partnerfirmen nichts angehen (Outlook-Kontakte, die besuchten Internetseiten etc. pp. Die Facebook z.B. soll in der Lage sein ganze Systemabbilder zu erstellen und zu Facebook zu senden)
MaWin schrieb: > Mir reicht schon mein mAuto, welches sämtliche ihm bekannten > Fehlermeldungen geheim hält Dafür gibt es Apps (z.B. Torque) für das Smartphone und ein Dongle für die Diagnoseschnittstelle. Die Autohersteller versuchen zwar nicht alle PIDs öffentlich zu machen, aber die wichtigsten PIDs sind bekannt.
:
Bearbeitet durch User
Hallo Rufus. Rufus Τ. F. schrieb: > Die semantische Feinheit "passwortgeschützt aber nicht verschlüsselt" > diskutieren wir jetzt mangels Sinn nicht weiter aus. Ich hätte jetzt mal vermutet, dass er mit "passwortgeschützt aber nicht verschlüsselt" so etwas wie "signiert" meint. Also, jeder kann zwar die Datei lesen, aber durch die Signatur ist klargestellt 1) wer der Urheber ist, und 2) kann sie nicht manipuliert werden, ohne dass das bei einer Überprüfung der Signatur auffällt. Vieleicht könnte der TO das ja mal bestätigen, wenn es so ist. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Also, jeder kann zwar die Datei lesen Hm, warum schreibt er dann: Peter schrieb: > ...sodass keiner die Dateien ohne Passwort öffnen kann.
Hallo Hugo. Hugo E. schrieb: > Bernd W. schrieb: >> Also, jeder kann zwar die Datei lesen Das war mein Schluss aus: Peter schrieb: > Die Dateien sollen dabei nicht verschlüsselt > werden. > > Hm, warum schreibt er dann: > > Peter schrieb: >> ...sodass keiner die Dateien ohne Passwort öffnen kann. Genau den Widerspruch habe ich nicht verstanden, und darum Versucht irgendwie aufzulösen. Aber der TO korriegiert sich ja selber bei: Peter schrieb: > Ich muss das genauer erläutern: > Nun, Verschlüsselungsalgorithmen gibt es unmengen. Da wird schon was passendes für den TO bei sein. In 99% aller Fälle würde vermutlich rot13 schon langen. ;O) Mein Tipp an den TO: Als OpenSource veröffentlichen und von den Verbesserungen lernen, die andere daran machen. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Peter schrieb: > Ich brauch kein Argument, um die Debug-Dateien unleserlich zu gestalten. > Es geht den Kunden einfach nichts an. Du hast nicht das Recht Debug-Infos, welche beim Kunden generierte werden, ihm vorzuenthalten!
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.