Hallo,

Mein Programm hat einen Status erreicht, indem ich es nun weiterverteilen möchte an Tester. Einmal benutze ich dafür die ClickOnce-Veröffentlichung auf einem Netzwerkpfad und einmal debug/release lokal und kopiere dann im zweiten Fall alle nötigen Dateien auch auf das Netzlaufwerk. Wenn ich von der Maschine aus, auf der ich auch entwickle die Installation durchführe klappt das fehlerfrei. Genauso das direkte starten der exe mit der zweiten Variante. Nun möchte aber ein Kollege an einem Vista-Client das Programm ausführen und da gehen beide Varianten in die Hose. Dabei wird folgendes geschmissen:
Beschreibung:

Stopped working

Problemsignatur:

Problemereignisname:
CLR20r3

Problemsignatur
01:
myprogram.exe

Problemsignatur
02: 1.0.0.0

Problemsignatur
03: 51752827

Problemsignatur
04: mscorlib

Problemsignatur
05: 4.0.30319.17929

Problemsignatur
06: 4ffa561c


Problemsignatur
07: 43c4

Problemsignatur
08: 13c

Problemsignatur
09: System.UnauthorizedAccess

Betriebsystemversion:
6.0.6002.2.2.0.256.6

Gebietsschema-ID:
1031



Ich habe es bereits mit und ohne Signierung versucht. Anscheinend mache ich aber immer noch was falsch. Der Client hat übrigens .Net 4.5 drauf und mein Programm braucht nur 4.0.

Wie veröffentliche ich mein Programm möglichst einfach (und möglichst auch ohne Setup) und auch so, dass selbst Vista-Maschinen damit klar kommen?

Gruß

Kopier einfach die Datei Programmname.exe aus dem Ordner Programmordner\bin\Debug.
Das beinhaltet dein gesamtes Programm. Falls du Erweiterungen eingebunden hast, musst du diese auch Kopieren.

Wie ich bereits sagte, habe ich das bereits gemacht. Inklusive dll's die mein Programm benötigt. Ohne alles gehts nämlich in die Hose.

Gerade hat ein anderer Kollege es auf einem Windows 8 Rechner direkt zum Laufen bekommen. Ich selbst verwende Windows 7.
Auf 7 & 8 funktioniert es also, bei Vista startet das Programm nicht.

Es gab da schonmal soetwas: vbforums.com/showthread.php?58…authorizedAccessException

Mir fällt gerade auf, dass Registry-Zugriffe meines Wissens nach nur mit Adminrechten möglich sind. Da ich im Load des Programms einen kleinen Check auf die Registry mache, wird da dann auch die Unauthorized-Exception geschmissen. Ich glaube um die zwingende Notwendigkeit von Adminrechten zu umgehen, speicher ich meine Settings lieber nicht in der Registry.
Was ist der eleganteste Weg um Einstellungen wie zB Zugangsdaten sicher, lokal zu speichern und beim starten des Programms zu laden?

man könnte sie verschlüsseln und als eine datei irgendwo reinspeichern z.b. als registryEnter.dat die würde keiner anrühren

@Schlammy
Dieser Ansatz ist ziemlich unsicher, da man verschlüsselte Sachen immer wieder entschlüsseln kann. Außerdem bringt (zumindest mich) eine Datei mit einem Systemnamen, den ich nicht kenne grad dazu, sie zu öffnen ;).

ja kann man. so gesehen ist aber auchwieder nix richtig sicher oder nicht? Ich wollte nur eine Lösungsmöglichkeit geben bitte reisst mir nicht gleich den Kopf ab

Also Einstellungen in den My.Settings
Zugangsdaten (bitte nicht in My.Settings) sollten Verschlüsselt liegen.
Ich empfehle AppData (da dort auf jeden Fall Schreibrechte vorhanden sind).

Mach nicht den Fehler lokale Daten (im Programmordner) ändern zu wollen. Sowas führt in unserem Hause hier zB. immer zu Problemen, da Programme im Programme-Ordner liegen und dort nur Administratoren Schreibrechte haben.

EDIT: Ich gehe davon aus, dass die Zugangsdaten gespeichert werden sollen in Sachen "Passwort Speichern - Haken".
Ansonsten sind Hashes der Richtige Weg.

Ich würde, wenn es nicht so sicher sein muss, einfach den Hash (nicht md5, sondern SHA512) in den Settings speichern und dann immer prüfen (Hashes lassen sich nicht zurückverwandeln). Wenn es sicher sein soll, würde ich es wie in der ersten Möglichkeit machen, den Hash allerdings auf einem Webserver speichern.

@Schlammy
Sorry, war nicht so gemeint ;).

Was ich auch gerne mache sind sogenannte Binärdateien.

Sprich: Du erstellst dir Klassen in denen du deine Daten speicherst... (Mit dem Zusatz: <Serializable()> kannst du eine ganze Klasse speichern)
Von diesen Klassen machst du dir ne Liste...
Diese Liste kannst du dann als Binärdatei rausschreiben.
Je nachdem wie sicher das ganze sein soll, kannst du die Datei natürlich verschlüsseln.

@MemoAnMichSelbst
Das Problem hierbei ist, dass du verschlüsselte Dateien wieder entschlüsseln kannst, was wiederum bewirkt, dass du als Angreifer mit der Hilfe eines einfachen Tools das Passwort rausbekommen kannst und, wenn der Benutzer für viele Dienste dasselbe Passwort benutzt (kenn ich viele), hast du seine Zugangsdaten, was dann böse enden kann.

Da hast du natürlich recht...
Keine Frage...

Jedoch so ne Passwort-Speichern Methode kommt mit nem Hash nicht aus. oO Da kannst du dich biegen und drehen wie du willst.
Wenn er eine solche Funktion (die mittlerweile ja in jedem Browser zur Verfügung steht) anbieten will... Wird er das eingegebene Passwort verschlüsseln müssen.

Wenn er nur die Passwörter zum Vergleichen aufbewahren will, sollte er das natürlich als Hash tun. Habe ich aber auch so geschreibselt

Also ich stelle gerade auf My.Settings um.
Für die user + pw Kombination habe ich sonst zum Speichern dieser in der Registry diese sensiblen Informationen mit TripleDES verschlüsselt, mit einem Passwort welches sich der User selbst aussuchen kann.
Soweit ich weiß sollte TripleDES in diesem Anwendungsfall (Lokale RegistryKeys, dessen Pfad für mögliche Angreifer erst einmal unbekannt sind) aufjedenfall genügen. Aufgrund der leichten Implementierung war es für mich auch ein leichtes das zum Laufen zu bekommen. Das selbe wollte ich nun auch für die entsprechenden Settings in My.Settings machen. Das dürfte sicherheitstechnisch mehr als ausreichend sein, da man sich erstmal Zugang zum generierten Code schaffen muss und dann auch noch das Passwort knacken muss. Denn selbst wenn das Passwort per KeyLogger ausgelesen wird, ist das ja nur das Passwort um an das Passwort zu kommen. Man braucht also immer noch den entsprechenden Datensatz und muss dann noch den richtigen Entschlüsselungsmechanismus finden.

Sehe ich hier etwas Grundlegendes falsch, oder ist das so angemessen?

naja,

wo die My.Settings gespeichert sind, weiß jeder und jeder kann sie auslesen (es handelt sich hierbei um eine XML).

Ok das mag sein, dennoch braucht man erstmal Zugriff darauf und immer noch das Passwort. Oder reicht das nich?

Um Zugriff auf die XML zu bekommen reicht der Internet-Explorer
Wenn du das Passwort dort verschlüsselt speicherst, kann man damit natürlich nur das Verschlüsselte Passwort sehen.

Wobei ich dir ans Herz legen würde, immer Hash's (oder schreibt man Hashes?!) von Passwörtern zu verwenden.

Hashes von welchem Passwort? Von dem mit dem ich die Zugangsdaten verschlüssele? Quasi bevor ich die Daten direkt mit dem Passwort verschlüssele, ein Hash vom Pw erstellen um größere Komplexität (durch mehr Zeichen) zu erreichen? Ist es dann aber nicht möglich, dass vielleicht irgendwelche Passwortkombination den selben Hashcode produzieren, die Daten also auch mit mehreren Passwörtern entschlüsselt werden kann?

Rein theoretisch ist das möglich
Aber extremst unwahrscheinlich...
Ich würd sagen du wirst schneller vom UFO entführt

Naja ich weiß nicht was für ein Passwort das sein soll.

Willst du Passwörter speichern, welche zum Zugriff auf einen FTP verwendet werden? (hab gerade deine andere Frage gelesen).
Dann bringen dir Hashes natürlich nichts, die kannst ja nicht wieder zurückrechnen.

Du wolltest dir im Klaren sein, dass man vb.net Programme decompilieren kann und somit an deinen Quellcode kommt!

Ja genau, es handelt sich um Zugangsdaten für FTP(S).
Was aber funktionieren würde wäre:

Passwort für TripleDES eingeben -> Hash vom Passwort erstellen -> TripleDES mit dem gehashten PW auf die Zugangsdaten anwenden. Beim decrypten dann wieder das selbe Spiel. Ist bloß die Frage, ob das wirklich die Sicherheit erhöht.

Genau deswegen, weil ich mir über die Dekompilierung im klaren bin, vercode ich keine harten Passwörter und das TripleDES-PW wird nirgendwo gespeichert. Deshalb sieht man in meinem Quellcode ja nur, dass ich TripleDES benutze und man findet in den My.Settings auch die chiffrierten Zugangsdaten. Wenn man TripleDES nicht knacken kann und das Passwort womit die Zeichen verschlüsselt wurde, ist man doch eigentlich sicher.

Ich könnte mir nur vorstellen, dass jemand auf Basis meines Quellcodes mein Programm manipulieren / hooken kann und sich dann das eingegebene Passwort zur Laufzeit unverschlüsselt krallt. Aber da hätte ich auch keine Idee, wie ich mich dagegen schützen sollte. Andererseits hat man schon enorme andere Probleme, wenn es soweit kommt.