Hey,
wenn es sich um ein VB.NET Programm handelt, leider NEIN. Da diese Dekompiliert werden können, und man sich dadurch den Sourcecode ansehen kann.
Was du allerdings tun könntest wäre eine Schnittstelle auf einem Webserver bereitszustellen über welchr dir Datenbank Komunikation abläuft.

BEISPIEL: blablub.de/login/username/password ...
Antwort des Servers dann Login Ok oder Login fehlerhaft.

Hoffe du verstehst was ich meine.

Grüße
Marcel

Im Normalfall speichert man in der DB auch kein Passwort (mehr). Man speichern nur noch den gesalzenen Hash des Passwortes. Wie es jetzt mir dem Username/Mail-Adresse aussieht, weiß ich jetzt ned. Muss evtl wer anders beantworten.
In deinem (VB-)Client hingegen gibt der User nur den Usernamen und sein Passwort an. Daraufhin erstellt das Programm (je nachdem, s.o.) für den Usernamen und das Passwort einen Hash. Der wird an die Datenbank geschickt und geprüft ob es eine Übereinstimmung gib (einen Treffer). Wenn ja, dann ist der User authentifizier und kann auf den "Member-Bereich" zugreifen.

Das ganze lässt sich abstrakt auf jede erdenkliche Anwendung übertragen. Nur die jeweilige Implementierung ist anders. In VB wirst du halt einen (verschlüsselten) Webrequest ansetzen müssen und auf die Antwort warten. In einer Webanwendung entweder über JavaScript und einem (Ajax) Request oder in PHP mit dortigen Mitteln.

Alles andere wäre fahrlässig, wennicht grob fahrlässig. Wie bereits @Marcel1997 gesgt hat: Einen VB-Client kann man leicht decompilen, ist ja nur Bytecode. Notfalls geht das auch mit .NET-Boardmitteln (disasm.exe).
Nicht anders ist das in heutigen Web-Applikationen. Hier wird auch das Passwort nicht im Code gespeichert, sondern in PHP mit Sessions übergeben, bzw in einer Session gespeichert.

Hoff ich konte helfen,
Lg Radinator

Radinator schrieb:

ist ja nur Bytecode

Wenn schon dann richtig:
eine .NET Applikation liegt zunächst als IL vor, um dann zur Laufzeit in Maschinencode umgewandelt zu werden.
Dieser IL-Code ist nach wie vor Menschenlesbar und Programme wie ILSpy sind in der Lage dies nicht nur zu decompilieren, sondern sogar wieder zurück in C# oder VB.NET zu verwandeln.

Egal welche Programmiersprache du verwendest. Speichere NIEMALS sensible Daten in deinem Code.
Alles was am Client ist lässt sich auf einfachere bis etwas schwierigere Weise auslesen und abfangen.

(Nur um Missverständnisse zu vermeiden weil die Vorposter explizit .NET ansprechen.)

weil das zum thema passt:
ich hatte mal eine php schnittstelle über die mein vb.net programm z.B. versucht hat sich einzuloggen. Funktionierte zwar wunderbar aber ich konnte einfach einen host-eintrag in der host datei machen und somit die abfrage umlenken und somit konnte man das ergebnis der abfrage nach belieben fälschen. Wie kann man sowas verhindern?

Eigentlich gar ned. Die Host Datei ist nur bearbeitbar mit Admin Rechten. Wenn du ein Programm mit höchsten Privilegien startest, wirst du wohl Schwierigkeiten haben, das zu verhindern.

Edit: @Mono:

Mono schrieb:

(Nurum Missverständnisse zu vermeiden weil die Vorposter explizit .NET ansprechen.)

Deswegen habe ich ja auch in meinem Post folgendes gesagt:

Radinator schrieb:

Das ganze lässt sich abstrakt auf jede erdenkliche Anwendung übertragen.

@TE:
Wie bereits von mir gesagt und von anderen Bestätigt: Speichere NIEMALS Passworter und andere sensible Daten "hardcode" oder irgendwo in deiner Awendung. Falls du mal ein Passwort länger brauchst, als nur zum anmelden, weil du etwa jede Transaktion (ist jetzt nur ein Bsp) mit dem Passwort verifizieren willst, dann gibt es im Namespace System.Security die Klasse SecureString. Die ist für sowas geeignet. Und genau so ist es auch mit Login-Daten. Sobald irgendwer es schafft sich Zugang zu dem Datenbestand zu verschaffen, in dem die Daten ungehashed (nicht unverschlüsselt) vorliegen, hast du verloren. Wenn du jedoch die Passwörter Hashsd und am besten auch noch saltest, dann wird sich der Angreifer, je nach Stärke des Saltes und des Hashverfahrens sowie der Stärke der PW sich die Zähne ausbeißen. Da er zu jedem Hash genau den richtigen Salt finden muss.

Mir ist bewusst, dass er dazu erst einmal Zugang zur DB erhalten muss und dass das schon mal schwer genug ist, ich will dir aber hier auch nur die Folgen aufzeigen, die eine Anwendung im Worst Case haben kann, wenn man nicht richtig mit den sensiblen Daten umgeht.

windowsfan schrieb:

weil das zum thema passt:
ich hatte mal eine php schnittstelle über die mein vb.net programm z.B. versucht hat sich einzuloggen. Funktionierte zwar wunderbar aber ich konnte einfach einen host-eintrag in der host datei machen und somit die abfrage umlenken und somit konnte man das ergebnis der abfrage nach belieben fälschen. Wie kann man sowas verhindern?

Gar nicht. Es gibt sogar noch viel mehr Wege dies zu bewerkstelligen. Also wenn es nur ein Login zu deinem Programm sein soll, dann vergiss es. Solche Logins sind ja eigentlich eher dafür gedacht, dass man einen User identifizieren kann für weitere Anfragen und wenn regelmässig Daten zwischen Client und Server ausgetauscht werden.
Als reines Lizenzierungsmodell mit einem einmaligen Login oder so ist es nutzlos.

windowsfan schrieb:

das ergebnis der abfrage nach belieben fälschen

Es ist nicht einfach (und man kann vieles falsch machen), aber mit TLS und der entsprechenden Konfiguration müsste sich MITM verhindern lassen.
Beim Login überträgst du ein Token, das für jede weitere Interaktion mit dem Server genutzt werden muss und auch entsprechend geprüft wird.
Wer dann bei sich lokal gerne rumbastelt, kann das tun - der Server akzeptiert nur das ausgestellte Token und regelt damit, ob Zugriffe auf die API berechtigt sind oder eben nicht.

Radinator schrieb:

je nach Stärke des Saltes und des Hashverfahrens sowie der Stärke der PW sich die Zähne ausbeißen. Da er zu jedem Hash genau den richtigen Salt finden muss

Du scheinst Ahnung von der Materie zu haben, ein paar Dinge möchte ich hier aber noch etwas klarer darstellen:
Es ist ein gängiges Verfahren, den Salt mitzuspeichern. Das Konzept hinter dem Salt ist nur ein Schutz gegen vorberechnete Hashes.
Zur Stärke: Ein geändertes Bit als Salt reicht, um eine Tabelle unbrauchbar zu machen.
Mit längerem Salt steigerst du die Wahrscheinlichkeit, dass keine Tabelle für diesen Salt verfügbar ist.
Mit einem für jedes Passwort geänderten Salt (=> Salt mit zum Passwort speichern) schützt du andere Passwörter, denn beim Knacken eines Passwortes entsteht ja auch automatisch eine Liste mit anderen Hashes zu diesem Salt.

Hast du denn die HttpPostRequestLib als verweiss zu deinem Projekt hinzugefügt?

Wer in C# Passwörter im Source hat, kann sie gleich dem Angreifer als txt übergeben werden.
Mach es über PHP , das ist Serverseitig und kein Angreifer kann jemals die Credentials extrahieren.

Es gibt keine Methode die sicher ist.. was soll das überhaupt heißen.
Ein Safe ist auch nicht sicher, wenn das Passwort 0000 ist.

Mach es über php.

Es ist gar nicht zwingend nötig, dafür PHP zu verwenden. (Ich würde sogar sagen, dass PHP die denkbar schlechteste Option ist.)
Es ist möglich, einen MySQL-Benutzer anzulegen, der nur die benötigten Rechte für die benötigten Datenbanken bzw. Objekte hat. Das kann auch so weit gehen, dass man dem Benutzer nur das Execute-Recht gibt und alles über Stored Procedures laufen lässt. Je nach Anwendungsfall gibt es unterschiedliche Möglichkeiten. Das hat den Vorteil, dass man mit anständigen Bibliotheken (wie z.B. dem "Connector/Net") arbeiten kann, die einem die Daten bequem und stark typisiert liefern, anstatt alles mit Strings und WebRequests von Hand zu machen. Und mit PHP hat man gleich noch das Problem, dass man alle Daten durch eine schrottige, untypisierte Sprache drücken muss. Ist dann immer schön, wenn man mit Datums- und Zeitangaben als Strings in 10 verschiedenen Formaten rumhantieren muss.

WebServices.

Niko Ortner schrieb:

(Ich würde sogar sagen, dass PHP die denkbar schlechteste Option ist.)

xX-Nick-Xx schrieb:

PHP*

@Niko Ortner Tut mir leid, aber das Bild von dir beziehen ich eher auf deine Aussage. Oder siehst du wirklich PHP als die denkbar schlechteste Option an? Ich meine, findest du z.B. einen Upload einer txt per FTP in ein bestimmtes Verzeichnis, wo ein Programm ständig pollt und auf die entsprechende Datei wartet, um daraus eine E-Mail zu generieren, diese an einen "E-Mail to letter" Dienst schickt, um einen echten Brief zu versenden, worauf eine Mitarbeiter von Hand in der SQL Datenabank nachschaut ob der Login korrekt ist, besser?

Ich befürchte, dass @Niko Ortner damit nur eine Krankheit alleine meinte, und nicht die Mischung aus Pest, Cholera und nem schlechten Scherz

​Es ist möglich, einen MySQL-Benutzer anzulegen, der nur die benötigten Rechte für die benötigten Datenbanken bzw. Objekte hat.

Würde ich nie empfehlen. Dazu müsste die Datenbank übers Internet erreichbar sein. Dies ist in jedem Fall ein potentieller Angriffspunkt mehr und daher definitiv unsicherer als ein Webservice.
Ein Webservice ist in meinen Augen "the way to go". Ob dieser in PHP, Python, ASP.NET, Perl oder Java geschrieben ist ist für mich Geschmackssache.